Peter Saint-Andre 12 years ago
parent
commit
56412aa8c0
84 changed files with 249 additions and 273 deletions
  1. 12
    23
      all.sh
  2. 12
    12
      deferred.py
  3. 2
    14
      fo.xsl
  4. 1
    1
      gps_datum.html
  5. 11
    11
      inxep.py
  6. 1
    1
      ipr-policy.shtml
  7. 10
    10
      lastcall.py
  8. 3
    3
      protopage.xsl
  9. 1
    1
      submit.shtml
  10. 12
    12
      xep-0001.xml
  11. 1
    1
      xep-0002.xml
  12. 1
    1
      xep-0005.xml
  13. 2
    2
      xep-0006.xml
  14. 1
    1
      xep-0007.xml
  15. 2
    2
      xep-0008.xml
  16. 2
    2
      xep-0010.xml
  17. 7
    7
      xep-0011.xml
  18. 1
    1
      xep-0012.xml
  19. 1
    1
      xep-0014.xml
  20. 2
    2
      xep-0015.xml
  21. 3
    3
      xep-0018.xml
  22. 15
    15
      xep-0019.xml
  23. 2
    2
      xep-0021.xml
  24. 2
    2
      xep-0022.xml
  25. 6
    6
      xep-0023.xml
  26. 2
    2
      xep-0024.xml
  27. 1
    1
      xep-0025.xml
  28. 8
    8
      xep-0026.xml
  29. 4
    4
      xep-0029.xml
  30. 1
    1
      xep-0032.xml
  31. 3
    3
      xep-0035.xml
  32. 1
    1
      xep-0037.xml
  33. 1
    1
      xep-0038.xml
  34. 1
    2
      xep-0039.xml
  35. 4
    4
      xep-0042.xml
  36. 4
    4
      xep-0043.xml
  37. 2
    2
      xep-0045.xml
  38. 1
    1
      xep-0051.xml
  39. 1
    1
      xep-0052.xml
  40. 5
    5
      xep-0055.xml
  41. 3
    3
      xep-0057.xml
  42. 2
    2
      xep-0066.xml
  43. 2
    2
      xep-0067.xml
  44. 1
    1
      xep-0068.xml
  45. 2
    2
      xep-0071.xml
  46. 3
    3
      xep-0072.xml
  47. 1
    1
      xep-0075.xml
  48. 4
    4
      xep-0077.xml
  49. 1
    1
      xep-0078.xml
  50. 2
    2
      xep-0079.xml
  51. 1
    1
      xep-0080.xml
  52. 2
    2
      xep-0095.xml
  53. 5
    5
      xep-0097.xml
  54. 2
    2
      xep-0099.xml
  55. 1
    1
      xep-0103.xml
  56. 1
    1
      xep-0104.xml
  57. 6
    6
      xep-0107.xml
  58. 1
    1
      xep-0109.xml
  59. 1
    1
      xep-0111.xml
  60. 1
    1
      xep-0116.xml
  61. 1
    1
      xep-0118.xml
  62. 6
    6
      xep-0120.xml
  63. 1
    1
      xep-0121.xml
  64. 1
    1
      xep-0125.xml
  65. 1
    1
      xep-0128.xml
  66. 1
    1
      xep-0129.xml
  67. 1
    1
      xep-0131.xml
  68. 1
    1
      xep-0134.xml
  69. 5
    5
      xep-0137.xml
  70. 1
    1
      xep-0141.xml
  71. 5
    5
      xep-0144.xml
  72. 3
    3
      xep-0145.xml
  73. 2
    2
      xep-0146.xml
  74. 1
    1
      xep-0148.xml
  75. 1
    1
      xep-0153.xml
  76. 1
    1
      xep-0154.xml
  77. 3
    3
      xep-0155.xml
  78. 2
    2
      xep-0156.xml
  79. 1
    1
      xep-0166.xml
  80. 3
    3
      xep-0172.xml
  81. 4
    4
      xep-0175.xml
  82. 7
    7
      xep-0176.xml
  83. 1
    1
      xep-0182.xml
  84. 2
    2
      xep-template.xml

+ 12
- 23
all.sh View File

@@ -1,31 +1,20 @@
1 1
 #!/bin/sh
2
-# for each XEP, generates HTML file and IETF reference, then copies XML file
3
-# also generates HTML for the README and template
4
-# finally, copies the stylesheet, DTD, and schema
5
-# usage: ./all.sh
2
+# for one XEP, generates HTML file and IETF reference, then copies XML file
3
+# usage: ./gen.sh xxxx 
4
+# (where xxxx is the 4-digit XEP number)
6 5
 
7 6
 xeppath=/var/www/stage.xmpp.org/extensions
8 7
 
9
-ls xep-0*.xml > tmp.txt
10
-sed s/xep-\(.*\).xml/\1/ tmp.txt > nums.txt
11
-rm tmp.txt
8
+xsltproc xep.xsl xep-$1.xml > $xeppath/jep-$1.html
9
+xsltproc ref.xsl xep-$1.xml > $xeppath/refs/reference.JSF.XEP-$1.xml
12 10
 
13
-while read f
14
-do
15
-    xsltproc xep.xsl xep-$f.xml > $xeppath/xep-$f.html
16
-    xsltproc ref.xsl xep-$f.xml > $xeppath/refs/reference.JSF.XEP-$f.xml
17
-    cp xep-$f.xml $xeppath/
18
-done < nums.txt
11
+cp xep-$1.xml $xeppath/
19 12
 
20
-rm nums.txt
21
-
22
-xsltproc xep.xsl xep-README.xml > $xeppath/README.html
23
-xsltproc xep.xsl xep-template.xml > $xeppath/template.html
24
-
25
-cp xep.dtd $xeppath/
26
-cp xep.ent $xeppath/
27
-cp xep.xsd $xeppath/
28
-cp xep.xsl $xeppath/
13
+cp *.dtd $xeppath/
14
+cp *.ent $xeppath/
15
+cp *.gif $xeppath/
16
+cp *.html $xeppath/
17
+cp *.shtml $xeppath/
18
+cp *.xsd $xeppath/
29 19
 
30 20
 # END
31
-

+ 12
- 12
deferred.py View File

@@ -2,7 +2,7 @@
2 2
 
3 3
 # File: deferred.py
4 4
 # Version: 0.2
5
-# Description: a script for setting a JEP to Deferred
5
+# Description: a script for setting a XEP to Deferred
6 6
 # Last Modified: 2006-04-24
7 7
 # Author: Peter Saint-Andre (stpeter@jabber.org)
8 8
 # License: public domain
@@ -33,7 +33,7 @@ now = int(time.time())
33 33
 
34 34
 # READ IN ARGS: 
35 35
 #
36
-# 1. JEP number
36
+# 1. XEP number
37 37
 # 2. database user
38 38
 # 3. database password
39 39
 
@@ -43,7 +43,7 @@ dbpw = sys.argv[3];
43 43
 
44 44
 jepfile = jepnum + '/jep-' + jepnum + '.xml'
45 45
 
46
-# PARSE JEP HEADERS:
46
+# PARSE XEP HEADERS:
47 47
 #
48 48
 # - title
49 49
 # - abstract
@@ -79,7 +79,7 @@ remark = getText(remarkNode.childNodes)
79 79
 # name is $title
80 80
 # type is $jeptype
81 81
 # status is $jepstatus
82
-# notes is "Version $version of JEP-$jepnum released $date."
82
+# notes is "Version $version of XEP-$jepnum released $date."
83 83
 # version is $version
84 84
 # last_modified is $now
85 85
 # abstract is $abstract
@@ -87,7 +87,7 @@ remark = getText(remarkNode.childNodes)
87 87
 
88 88
 db = MySQLdb.connect("localhost", dbuser, dbpw, "foundation")
89 89
 cursor = db.cursor()
90
-theNotes = "Version " + version + " of JEP-" + jepnum + " released " + date + "; consideration deferred because of inactivity."
90
+theNotes = "Version " + version + " of XEP-" + jepnum + " released " + date + "; consideration deferred because of inactivity."
91 91
 theLog = remark + " (" + initials + ")"
92 92
 theStatement = "UPDATE jeps SET name='" + title + "', type='" + jeptype + "', status='Deferred', notes='" + theNotes + "', version='" + str(version) + "', last_modified='" + str(now) + "', abstract='" + abstract + "', changelog='" + theLog + "' WHERE number='" + str(jepnum) + "';"
93 93
 cursor.execute(theStatement) 
@@ -97,15 +97,15 @@ result = cursor.fetchall()
97 97
 #
98 98
 # From: editor@jabber.org
99 99
 # To: standards-jig@jabber.org
100
-# Subject: DEFERRED: JEP-$jepnum ($title)
100
+# Subject: DEFERRED: XEP-$jepnum ($title)
101 101
 # Body:
102
-#    JEP-$jepnum ($title) has been Deferred because of inactivity.
102
+#    XEP-$jepnum ($title) has been Deferred because of inactivity.
103 103
 #
104 104
 #    Abstract: $abstract
105 105
 #
106 106
 #    URL: http://www.jabber.org/jeps/jep-$jepnum.html
107 107
 #
108
-#    If and when a new revision of this JEP is published,
108
+#    If and when a new revision of this XEP is published,
109 109
 #    its status will be changed back to Experimental.
110 110
 #
111 111
 
@@ -115,14 +115,14 @@ fromaddr = "editor@jabber.org"
115 115
 # for real...
116 116
 toaddrs = "standards-jig@jabber.org"
117 117
 
118
-thesubject = 'DEFERRED: JEP-' + jepnum + " (" + title + ")"
119
-introline = 'JEP-' + jepnum + ' (' + title + ') has been Deferred because of inactivity.'
118
+thesubject = 'DEFERRED: XEP-' + jepnum + " (" + title + ")"
119
+introline = 'XEP-' + jepnum + ' (' + title + ') has been Deferred because of inactivity.'
120 120
 abstractline = 'Abstract: ' + abstract
121 121
 urlline = 'URL: http://www.jabber.org/jeps/jep-' + jepnum + '.html'
122
-endline = 'If and when a new revision of this JEP is published, its status will be changed back to Experimental.'
122
+endline = 'If and when a new revision of this XEP is published, its status will be changed back to Experimental.'
123 123
 
124 124
 #msg = "From: %s\r\n" % fromaddr
125
-msg = "From: JEP Editor <%s>\r\n" % fromaddr
125
+msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr
126 126
 msg = msg + "To: %s\r\n" % toaddrs
127 127
 msg = msg + "Subject: %s\r\n" % thesubject
128 128
 msg = msg + introline

+ 2
- 14
fo.xsl View File

@@ -27,7 +27,7 @@
27 27
       <page-sequence master-reference="jep_sequence">
28 28
         <flow flow-name="xsl-region-body" font-family="serif" color="black" font-size="10pt">
29 29
           <block space-before="1.5in" text-align="right" font-family="sans-serif" font-size="18pt">
30
-            JEP-<xsl:value-of select="/jep/header/number"/>
30
+            XEP-<xsl:value-of select="/jep/header/number"/>
31 31
           </block>
32 32
           <block text-align="right" font-family="sans-serif" font-size="18pt">
33 33
             <xsl:value-of select="/jep/header/title"/>
@@ -105,21 +105,9 @@
105 105
         </flow>
106 106
       </page-sequence>
107 107
       <page-sequence master-reference="std_page" initial-page-number="1">
108
-        <!--<static-content flow-name="xsl-region-before" margin-top=".5in">
109
-                    <block margin-left="1in" margin-right="1in" text-align-last="justify" font-size="9pt" font-family="sans-serif" color="silver">
110
-                        <xsl:value-of select="/jep/header/customer"/>
111
-                        <leader leader-pattern="space"/>
112
-                    Requirements Proposal
113
-                    </block>
114
-                    <block margin-left="1in" margin-right="1in" padding-bottom="10pt" border-after-color="black" border-after-width=".25pt" border-after-style="solid" text-align-last="justify" font-size="9pt" font-family="sans-serif" color="silver">
115
-                        <xsl:value-of select="/jep/header/title"/>
116
-                        <leader leader-pattern="space"/>
117
-                        <xsl:value-of select="/jep/header/revision[last()]/date"/>
118
-                    </block>
119
-                </static-content>-->
120 108
         <static-content flow-name="xsl-region-after">
121 109
           <block margin-left="1in" margin-right="1in" padding-top="10pt" border-before-color="black" border-before-width=".125pt" border-before-style="solid" text-align-last="justify" font-size="8pt" font-family="sans-serif" color="black">
122
-                        IJEP-<xsl:value-of select="/jep/header/number"/>:<xsl:text> </xsl:text>
110
+                        XEP-<xsl:value-of select="/jep/header/number"/>:<xsl:text> </xsl:text>
123 111
             <xsl:value-of select="/jep/header/title"/>
124 112
             <leader leader-pattern="space"/>
125 113
                         Page <page-number/> of <page-number-citation ref-id="lastpage"/>

+ 1
- 1
gps_datum.html View File

@@ -4,7 +4,7 @@
4 4
 </head>
5 5
 <body>
6 6
 <h1>GPS Datum Example</h1>
7
-<p>The following example of GPS datum differences was kindly provided by Randy Steele of Apollo, Pennsylvania (URL: &lt;<a href="http://www.nb.net/~resteele/">http://www.nb.net/~resteele/</a>&gt;) and is archived here so that a permanent link is available from <a href="http://www.jabber.org/jeps/jep-0080.html">JEP-0080: User Geolocation</a>.</p>
7
+<p>The following example of GPS datum differences was kindly provided by Randy Steele of Apollo, Pennsylvania (URL: &lt;<a href="http://www.nb.net/~resteele/">http://www.nb.net/~resteele/</a>&gt;) and is archived here so that a permanent link is available from <a href="http://www.xmpp.org/extensions/sep-0080.html">XEP-0080: User Geolocation</a>.</p>
8 8
 <p>BEGIN EXAMPLE</p>
9 9
 <hr />
10 10
 <p>This is an example of the differences in the datums you can use with a GPS.

+ 11
- 11
inxep.py View File

@@ -2,7 +2,7 @@
2 2
 
3 3
 # File: protojep.py
4 4
 # Version: 0.1
5
-# Description: a script for announcing proto-JEPs
5
+# Description: a script for announcing proto-XEPs
6 6
 # Last Modified: 2004-09-14
7 7
 # Author: Peter Saint-Andre (stpeter@jabber.org)
8 8
 # License: public domain
@@ -30,13 +30,13 @@ def getText(nodelist):
30 30
 
31 31
 # READ IN ARGS: 
32 32
 #
33
-# 1. JEP filename (sans extension)
33
+# 1. XEP filename (sans extension)
34 34
 
35 35
 jepname = sys.argv[1];
36 36
 
37 37
 jepfile = 'inbox/' + jepname + '.xml'
38 38
 
39
-# PARSE JEP HEADERS:
39
+# PARSE XEP HEADERS:
40 40
 #
41 41
 # - title
42 42
 # - abstract
@@ -70,9 +70,9 @@ remark = getText(remarkNode.childNodes)
70 70
 #
71 71
 # From: editor@jabber.org
72 72
 # To: standards-jig@jabber.org
73
-# Subject: LAST CALL: JEP-$jepnum ($title)
73
+# Subject: LAST CALL: XEP-$jepnum ($title)
74 74
 # Body:
75
-#    The JEP Editor has received a proposal for a new JEP.
75
+#    The XMPP Extensions Editor has received a proposal for a new XEP.
76 76
 #
77 77
 #    Title: $title
78 78
 #
@@ -80,8 +80,8 @@ remark = getText(remarkNode.childNodes)
80 80
 #
81 81
 #    URL: http://www.jabber.org/jeps/inbox/$jepname.html
82 82
 #
83
-#    The Jabber Council will now consider whether to accept
84
-#    this proposal as a full JEP.
83
+#    The XMPP Council will now consider whether to accept
84
+#    this proposal as a full XEP.
85 85
 #
86 86
 
87 87
 fromaddr = "editor@jabber.org"
@@ -90,15 +90,15 @@ fromaddr = "editor@jabber.org"
90 90
 # for real...
91 91
 toaddrs = "standards-jig@jabber.org"
92 92
 
93
-thesubject = 'proto-JEP: ' + title
94
-introline = 'The JEP Editor has received a proposal for a new JEP.'
93
+thesubject = 'proto-XEP: ' + title
94
+introline = 'The XMPP Extensions Editor has received a proposal for a new XEP.'
95 95
 titleline = 'Title: ' + title
96 96
 abstractline = 'Abstract: ' + abstract
97 97
 urlline = 'URL: http://www.jabber.org/jeps/inbox/' + jepname + '.html'
98
-actionline = 'The Jabber Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official JEP.'
98
+actionline = 'The XMPP Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official XEP.'
99 99
 
100 100
 #msg = "From: %s\r\n" % fromaddr
101
-msg = "From: JEP Editor <%s>\r\n" % fromaddr
101
+msg = "From: XEP Editor <%s>\r\n" % fromaddr
102 102
 msg = msg + "To: %s\r\n" % toaddrs
103 103
 msg = msg + "Subject: %s\r\n" % thesubject
104 104
 msg = msg + introline

+ 1
- 1
ipr-policy.shtml View File

@@ -79,7 +79,7 @@ License (&lt;http://creativecommons.org/by/2.5/&gt;).
79 79
   </pre></blockquote>
80 80
 <p><hr></p>
81 81
 <h3>Notes</h3>
82
-<p><a name="note1"></a>1. For information about XMPP Extension Protocols, see &lt;<a href="http://www.xmpp.org/extensions/">http://www.xmpp.org/extensions/</a>&gt; and <a href="http://www.xmpp.org/extensions/xep-0001.html">JEP-0001</a>.</p>
82
+<p><a name="note1"></a>1. For information about XMPP Extension Protocols, see &lt;<a href="http://www.xmpp.org/extensions/">http://www.xmpp.org/extensions/</a>&gt; and <a href="http://www.xmpp.org/extensions/xep-0001.html">XEP-0001</a>.</p>
83 83
 <p><a name="note2"></a>2. For information about intellectual property conservancies, see &lt;<a href="http://www.creativecommons.org/concepts/#ip">http://www.creativecommons.org/concepts/#ip</a>&gt; and M. van Houweling, "Cultivating Open Information Platforms: A Land Trust Model." <cite>Journal of Telecommunications &amp; High Technology Law</cite> 1, no. 1 (2002): 309-23.</p>
84 84
 <h3>Acknowledgements</h3>
85 85
 <p>Many thanks to Lawrence Lessig and Molly van Houweling for their assistance in formulating this policy.</p>

+ 10
- 10
lastcall.py View File

@@ -2,7 +2,7 @@
2 2
 
3 3
 # File: lastcall.py
4 4
 # Version: 0.2
5
-# Description: a script for announcing JEP Last Calls
5
+# Description: a script for announcing Last Calls
6 6
 # Last Modified: 2004-09-29
7 7
 # Author: Peter Saint-Andre (stpeter@jabber.org)
8 8
 # License: public domain
@@ -33,7 +33,7 @@ now = int(time.time())
33 33
 
34 34
 # READ IN ARGS: 
35 35
 #
36
-# 1. JEP number
36
+# 1. XEP number
37 37
 # 2. end date
38 38
 # 3. database user
39 39
 # 4. database password
@@ -45,7 +45,7 @@ dbpw = sys.argv[4];
45 45
 
46 46
 jepfile = jepnum + '/jep-' + jepnum + '.xml'
47 47
 
48
-# PARSE JEP HEADERS:
48
+# PARSE XEP HEADERS:
49 49
 #
50 50
 # - title
51 51
 # - abstract
@@ -81,7 +81,7 @@ remark = getText(remarkNode.childNodes)
81 81
 # name is $title
82 82
 # type is $jeptype
83 83
 # status is $jepstatus
84
-# notes is "Version $version of JEP-$jepnum released $date."
84
+# notes is "Version $version of XEP-$jepnum released $date."
85 85
 # version is $version
86 86
 # last_modified is $now
87 87
 # abstract is $abstract
@@ -89,7 +89,7 @@ remark = getText(remarkNode.childNodes)
89 89
 
90 90
 db = MySQLdb.connect("localhost", dbuser, dbpw, "foundation")
91 91
 cursor = db.cursor()
92
-theNotes = "Version " + version + " of JEP-" + jepnum + " released " + date + "; Last Call ends " + enddate + "."
92
+theNotes = "Version " + version + " of XEP-" + jepnum + " released " + date + "; Last Call ends " + enddate + "."
93 93
 theLog = remark + " (" + initials + ")"
94 94
 theStatement = "UPDATE jeps SET name='" + title + "', type='" + jeptype + "', status='Proposed', notes='" + theNotes + "', version='" + str(version) + "', last_modified='" + str(now) + "', abstract='" + abstract + "', changelog='" + theLog + "' WHERE number='" + str(jepnum) + "';"
95 95
 cursor.execute(theStatement) 
@@ -99,10 +99,10 @@ result = cursor.fetchall()
99 99
 #
100 100
 # From: editor@jabber.org
101 101
 # To: standards-jig@jabber.org
102
-# Subject: LAST CALL: JEP-$jepnum ($title)
102
+# Subject: LAST CALL: XEP-$jepnum ($title)
103 103
 # Body:
104 104
 #    This message constitutes notice of a Last Call
105
-#    for JEP-$jepnum ($title).
105
+#    for XEP-$jepnum ($title).
106 106
 #
107 107
 #    Abstract: $abstract
108 108
 #
@@ -118,14 +118,14 @@ fromaddr = "editor@jabber.org"
118 118
 # for real...
119 119
 toaddrs = "standards-jig@jabber.org"
120 120
 
121
-thesubject = 'LAST CALL: JEP-' + jepnum + " (" + title + ")"
122
-introline = 'This message constitutes notice of a Last Call for JEP-' + jepnum + ' (' + title + ').'
121
+thesubject = 'LAST CALL: XEP-' + jepnum + " (" + title + ")"
122
+introline = 'This message constitutes notice of a Last Call for XEP-' + jepnum + ' (' + title + ').'
123 123
 abstractline = 'Abstract: ' + abstract
124 124
 urlline = 'URL: http://www.jabber.org/jeps/jep-' + jepnum + '.html'
125 125
 schedline = 'This Last Call begins today and shall end at the close of business on ' + enddate + '.'
126 126
 
127 127
 #msg = "From: %s\r\n" % fromaddr
128
-msg = "From: JEP Editor <%s>\r\n" % fromaddr
128
+msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr
129 129
 msg = msg + "To: %s\r\n" % toaddrs
130 130
 msg = msg + "Subject: %s\r\n" % thesubject
131 131
 msg = msg + introline

+ 3
- 3
protopage.xsl View File

@@ -9,7 +9,7 @@
9 9
     <html>
10 10
       <head>
11 11
         <title><xsl:value-of select='/jep/header/shortname'/></title>
12
-        <link rel='stylesheet' type='text/css' href='/jeps/jep.css' />
12
+        <link rel='stylesheet' type='text/css' href='/xmpp.css' />
13 13
         <link rel='shortcut icon' type='image/x-icon' href='/favicon.ico' />
14 14
         <link>
15 15
           <xsl:attribute name='rel'><xsl:text>alternate</xsl:text></xsl:attribute>
@@ -39,9 +39,9 @@
39 39
             <xsl:value-of select='/jep/header/number'/>
40 40
             <xsl:text>.html</xsl:text>
41 41
           </xsl:attribute>
42
-          <xsl:text>JEP-</xsl:text><xsl:value-of select='/jep/header/number' />:<xsl:text> </xsl:text><xsl:value-of select='/jep/header/title' />
42
+          <xsl:text>XEP-</xsl:text><xsl:value-of select='/jep/header/number' />:<xsl:text> </xsl:text><xsl:value-of select='/jep/header/title' />
43 43
         </a>
44
-        (part of the <a href="http://www.jabber.org/jeps/">JEP series</a> published by the <a href="http://www.jabber.org/jsf/">Jabber Software Foundation</a>).</p>
44
+        (part of the <a href="http://www.jabber.org/jeps/">XEP series</a> published by the <a href="http://www.jabber.org/jsf/">Jabber Software Foundation</a>).</p>
45 45
 
46 46
         <xsl:variable name='schema.count' select='count(/jep/header/schemaloc)'/>
47 47
         <xsl:if test='$schema.count &gt; 0'>

+ 1
- 1
submit.shtml View File

@@ -8,7 +8,7 @@
8 8
 <li><p>Contact the <a href="editor.shtml">XMPP Extensions Editor</a> so that he knows to expect your submission.</p></li>
9 9
 <li><p>Write your proposal following the guidelines described in <a href="/extensions/xep-0143.html">XEP-0143: Guidelines for Authors of XMPP Extension Protocols</a>.</p></li>
10 10
 <li>Make sure you read, understand, and agree to the JSF's <a href="/extensions/ipr-policy.shtml">IPR Policy</a> before you submit your proposal!</li>
11
-<li><p>Email the XML file (or a URL for the file) to the <a href="editor.shtml">XMPP Extensions Editor</a> with a subject line of "ProtoJEP: [your title here]".</li>
11
+<li><p>Email the XML file (or a URL for the file) to the <a href="editor.shtml">XMPP Extensions Editor</a> with a subject line of "ProtoXEP: [your title here]".</li>
12 12
 </ol>
13 13
 <p><strong>Note:</strong> It is the author's responsibility to provide a properly-formatted source file (see the <a href='template.xml'>template</a> and <a href='http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/jeps/'>CVS repository</a>). Proposals submitted in HTML, TXT, MS Word, Open Document Format, etc. will be returned to the proposal author for proper formatting.</p>
14 14
 </div>

+ 12
- 12
xep-0001.xml View File

@@ -35,43 +35,43 @@
35 35
     <version>1.15</version>
36 36
     <date>2004-11-02</date>
37 37
     <initials>psa</initials>
38
-    <remark><p>Specified that a Standards Track JEP defines either (1) a wire protocol or (2) a protocol suite.</p></remark>
38
+    <remark><p>Specified that a Standards Track specification defines either (1) a wire protocol or (2) a protocol suite.</p></remark>
39 39
   </revision>
40 40
   <revision>
41 41
     <version>1.14</version>
42 42
     <date>2004-09-28</date>
43 43
     <initials>psa</initials>
44
-    <remark><p>Defined Procedural JEP type as the union of JIG Formation JEPs and certain Informational JEPs in order to clarify the JEP categories; added Modifications to Approved JEPs section in order to make explicit existing Council practices regarding Active and Final JEPs; specified that JEPs on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on JEPs for which it is the approving body, with all discussion to occur on the Standards-JIG list; updated the schema.</p></remark>
44
+    <remark><p>Defined Procedural type as the union of JIG Formation type and certain Informational specifications in order to clarify the categories; added Modifications to Approved Specifications section in order to make explicit existing Council practices regarding Active and Final specifications; specified that documents on which voting was not complete at the end of a Council term shall undergo a second Last Call and subsequent vote by the new Council; modified Proposal Process to specify that the Jabber Council shall issue Last Calls on documents for which it is the approving body, with all discussion to occur on the Standards-JIG list; updated the schema.</p></remark>
45 45
   </revision>
46 46
   <revision>
47 47
     <version>1.13</version>
48 48
     <date>2004-08-24</date>
49 49
     <initials>psa</initials>
50
-    <remark><p>Further specified the goals of the JEP process; mentioned Board-approved JEPs.</p></remark>
50
+    <remark><p>Further specified the goals of the standards process; mentioned Board-approved specifications.</p></remark>
51 51
   </revision>
52 52
   <revision>
53 53
     <version>1.11</version>
54 54
     <date>2004-07-14</date>
55 55
     <initials>psa</initials>
56
-    <remark><p>Specified the procedure for changing a JEP from Historical to Standards Track.</p></remark>
56
+    <remark><p>Specified the procedure for changing a XEP from Historical to Standards Track.</p></remark>
57 57
   </revision>
58 58
   <revision>
59 59
     <version>1.10</version>
60 60
     <date>2004-03-24</date>
61 61
     <initials>psa</initials>
62
-    <remark><p>Specified the procedure for acceptance of a proposal as a JEP; clarified the JEP types; completed editorial review.</p></remark>
62
+    <remark><p>Specified the procedure for acceptance of a proposal as a XEP; clarified the XEP types; completed editorial review.</p></remark>
63 63
   </revision>
64 64
   <revision>
65 65
     <version>1.9</version>
66 66
     <date>2003-12-22</date>
67 67
     <initials>psa</initials>
68
-    <remark><p>Added rule about automatic deferral of inactive JEPs.</p></remark>
68
+    <remark><p>Added rule about automatic deferral of inactive specifications.</p></remark>
69 69
   </revision>
70 70
   <revision>
71 71
     <version>1.8</version>
72 72
     <date>2003-10-06</date>
73 73
     <initials>psa</initials>
74
-    <remark><p>Clarified the definition of informational JEP.</p></remark>
74
+    <remark><p>Clarified the definition of informational specification.</p></remark>
75 75
   </revision>
76 76
   <revision>
77 77
     <version>1.7</version>
@@ -89,13 +89,13 @@
89 89
     <version>1.5</version>
90 90
     <date>2002-10-29</date>
91 91
     <initials>psa</initials>
92
-    <remark><p>Major revision based on experience. In addition to a reorganization of the content to improve the clarity of the presentation, changes include: (1) no anonymous authors; (2) proposal must be seconded by at least 5% of JSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a JEP (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the JSF Board and Jabber Council on 2002-11-20.</p></remark>
92
+    <remark><p>Major revision based on experience. In addition to a reorganization of the content to improve the clarity of the presentation, changes include: (1) no anonymous authors; (2) proposal must be seconded by at least 5% of JSF members before being proposed for a Council vote; (3) clarification that the Council votes only on a particular revision of a specification (e.g., version 1.3 when proceeding from Draft to Final); (4) added information about the "Call for Experience" phase before proceeding from Draft to Final; (5) added reference to RFC 2119; (6) added sections for security considerations, IANA considerations, and XMPP Registrar considerations. Approved by the JSF Board and Jabber Council on 2002-11-20.</p></remark>
93 93
   </revision>
94 94
   <revision>
95 95
     <version>1.4</version>
96 96
     <date>2002-01-16</date>
97 97
     <initials>psa</initials>
98
-    <remark><p>Added information about the new "Experimental" state for Standards Track JEPs and made appropriate changes to the JEP process.</p></remark>
98
+    <remark><p>Added information about the new "Experimental" state for Standards Track specifications and made appropriate changes to the standards process.</p></remark>
99 99
   </revision>
100 100
   <revision>
101 101
     <version>1.3.1</version>
@@ -107,19 +107,19 @@
107 107
     <version>1.3</version>
108 108
     <date>2001-10-23</date>
109 109
     <initials>psa</initials>
110
-    <remark><p>(1) Added information about the "cooling off" period before a Standards Track JEP may be advanced from Draft to Final; (2) Added a link to the JEP template file; (3) Performed several minor fixes.</p></remark>
110
+    <remark><p>(1) Added information about the "cooling off" period before a Standards Track specification may be advanced from Draft to Final; (2) Added a link to the template file; (3) Performed several minor fixes.</p></remark>
111 111
   </revision>
112 112
   <revision>
113 113
     <version>1.2</version>
114 114
     <date>2001-09-27</date>
115 115
     <initials>psa</initials>
116
-    <remark><p>(1) Added information about expiration dates; (2) Added a status of Deprecated to Standards Track JEPs.</p></remark>
116
+    <remark><p>(1) Added information about expiration dates; (2) Added a status of Deprecated to Standards Track specifications.</p></remark>
117 117
   </revision>
118 118
   <revision>
119 119
     <version>1.1</version>
120 120
     <date>2001-09-09</date>
121 121
     <initials>psa</initials>
122
-    <remark><p>(1) Changed "Jabber Foundation" to "Jabber Software Foundation"; (2) Changed "JIG Proposal JEP" to "JIG Formation JEP"; (3) Removed reference to the Secretary of the Jabber Software Foundation in connection with the role of JEP Editor; (4) Clarified the possible states of acceptance of each kind of JEP and described in greater detail the criteria for advancement from one state to another.</p></remark>
122
+    <remark><p>(1) Changed "Jabber Foundation" to "Jabber Software Foundation"; (2) Changed "JIG Proposal" to "JIG Formation"; (3) Removed reference to the Secretary of the Jabber Software Foundation in connection with the role of Editor; (4) Clarified the possible states of acceptance of each kind of specification and described in greater detail the criteria for advancement from one state to another.</p></remark>
123 123
   </revision>
124 124
   <revision>
125 125
     <version>1.0</version>

+ 1
- 1
xep-0002.xml View File

@@ -37,6 +37,6 @@
37 37
 <section1 topic='Explanation'>
38 38
   <p>The main function of most JIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs <note>For information about XMPP Extension Protocols, see <link url="http://www.xmpp.org/extensions/xep-0001.html">http://www.xmpp.org/extensions/xep-0001.html</link>.</note>) within a reasonably limited period of time. However, at the discretion of the XMPP Council, a handful of standing JIGs may be approved (e.g., to address security or standards compliance).</p>
39 39
   <p>Anyone (not limited to members of the Jabber Software Foundation) may propose the formation of a JIG by completing a XMPP Extension Protocol outlining the need for the JIG and its proposed focus. However, JIG leaders must be members of the Jabber Software Foundation. The number of leaders for a JIG is flexible, and shall be determined by each JIG, in consultation with the XMPP Council if necessary. The concept of "membership" with regard to JIGs is loose, and is essentially co-extensive with membership in the appropriate mailing list (each JIG has its own mailing list, which is archived for public review). JIG members do not need to be members of the Jabber Software Foundation, and any member of the general public may subscribe to JIG mailing lists.</p>
40
-  <p>It is expected that all JIGs (other than certain standing JIGs) will remain active for as long as necessary in order to produce one or more standards-track JEPs for review by the XMPP Council in the JIG's area of focus. However, if a JIG does not show signs of activity for an extended period of time (usually six months of inactivity on the JIG's mailing list), the JIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the JIG members (usually in the form of an email sent to the JIG's mailing list).</p>
40
+  <p>It is expected that all JIGs (other than certain standing JIGs) will remain active for as long as necessary in order to produce one or more standards-track specifications for review by the XMPP Council in the JIG's area of focus. However, if a JIG does not show signs of activity for an extended period of time (usually six months of inactivity on the JIG's mailing list), the JIG may be disbanded at the discretion of the XMPP Council with appropriate warning to the JIG members (usually in the form of an email sent to the JIG's mailing list).</p>
41 41
 </section1>
42 42
 </xep>

+ 1
- 1
xep-0005.xml View File

@@ -22,7 +22,7 @@
22 22
     <version>1.1</version>
23 23
     <date>2002-05-08</date>
24 24
     <initials>psa</initials>
25
-    <remark>Changed Status to Obsolete per approval of JEP-0019.</remark>
25
+    <remark>Changed Status to Obsolete per approval of XEP-0019.</remark>
26 26
   </revision>
27 27
   <revision>
28 28
     <version>1.0</version>

+ 2
- 2
xep-0006.xml View File

@@ -35,7 +35,7 @@
35 35
     <version>1.1</version>
36 36
     <date>2002-05-08</date>
37 37
     <initials>psa</initials>
38
-    <remark>Changed Status to Obsolete per approval of JEP-0019.</remark>
38
+    <remark>Changed Status to Obsolete per approval of XEP-0019.</remark>
39 39
   </revision>
40 40
   <revision>
41 41
     <version>1.0</version>
@@ -91,6 +91,6 @@
91 91
   <p>It is important to note that this JIG will not be a stand-alone JIG. It will draw upon many other JIGs (that currently exist and that have yet to be created). It will need encryption from the Security JIG for safe transfer of the information, a versatile forms format from the Forms JIG for Profiles administration, and advanced authentication from a future JIG for Services to authenticate the User against their Jabber account.</p>
92 92
 </section1>
93 93
 <section1 topic='History'>
94
-  <p>The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this JEP agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (<link url="http://www.theoretic.com/identity/">http://www.theoretic.com/identity/</link>), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official JIG that we have split the individual parts up, to make it easier to develop.</p>
94
+  <p>The concept of Jabber Profiles was started by Eric Murphy and Mike Hearn. They both had begun to come up with similar ideas, but did not meet and exchange ideas until around early 2001. Adam Theo also came across them soon after that, and after some discussion, the three authors of this document agreed to start a serious effort on developing it. We started it as a project at Theoretic Solutions (<link url="http://www.theoretic.com/identity/">http://www.theoretic.com/identity/</link>), although at that time it was as a full-fledged identity specification, complete with Profiles, Authentication, and Trust. It was not until we have now moved to set it up as an official JIG that we have split the individual parts up, to make it easier to develop.</p>
95 95
 </section1>
96 96
 </xep>

+ 1
- 1
xep-0007.xml View File

@@ -23,7 +23,7 @@
23 23
     <version>1.1</version>
24 24
     <date>2002-05-08</date>
25 25
     <initials>psa</initials>
26
-    <remark>Changed Status to Obsolete per approval of JEP-0019.</remark>
26
+    <remark>Changed Status to Obsolete per approval of XEP-0019.</remark>
27 27
   </revision>
28 28
   <revision>
29 29
     <version>1.0</version>

+ 2
- 2
xep-0008.xml View File

@@ -33,13 +33,13 @@
33 33
     <version>0.3</version>
34 34
     <date>2005-06-16</date>
35 35
     <initials>psa</initials>
36
-    <remark>Coincident with publication of JEP-0153, changed type to Historical.</remark>
36
+    <remark>Coincident with publication of XEP-0153, changed type to Historical.</remark>
37 37
   </revision>
38 38
   <revision>
39 39
     <version>0.2</version>
40 40
     <date>2003-05-06</date>
41 41
     <initials>psa</initials>
42
-    <remark>At the request of the authors, the status of this document has been changed to Retracted, to be superseded by a forthcoming JEP. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
42
+    <remark>At the request of the authors, the status of this document has been changed to Retracted, to be superseded by a forthcoming specification. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
43 43
   </revision>
44 44
   <revision>
45 45
     <version>0.1</version>

+ 2
- 2
xep-0010.xml View File

@@ -23,7 +23,7 @@
23 23
     <version>1.1</version>
24 24
     <date>2002-05-08</date>
25 25
     <initials>psa</initials>
26
-    <remark>Changed Status to Obsolete per approval of JEP-0019.</remark>
26
+    <remark>Changed Status to Obsolete per approval of XEP-0019.</remark>
27 27
   </revision>
28 28
   <revision>
29 29
     <version>1.0</version>
@@ -38,7 +38,7 @@
38 38
   <p>Therefore, the Whiteboard JIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing JIG <note>Conferencing protocol draft (<link url="http://jabber.org/?oid=1538">http://jabber.org/?oid=1538</link>)</note>.</p>
39 39
 </section1>
40 40
 <section1 topic='Deliverables'>
41
-  <p>The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council as a JEP):</p>
41
+  <p>The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):</p>
42 42
   <section2 topic='Requirements'>
43 43
     <p>A set of requirements that the proposed protocol should fulfill.</p>
44 44
   </section2>

+ 7
- 7
xep-0011.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
   <title>Jabber Browsing</title>
10
-  <abstract>This JEP defines a way to describe information about Jabber entities and the relationships between entities. Note: This JEP is superseded by JEP-0030: Service Discovery.</abstract>
10
+  <abstract>This document defines a way to describe information about Jabber entities and the relationships between entities. Note: This document is superseded by XEP-0030: Service Discovery.</abstract>
11 11
   &LEGALNOTICE;
12 12
   <number>0011</number>
13 13
   <status>Deprecated</status>
@@ -18,7 +18,7 @@
18 18
   </dependencies>
19 19
   <supersedes/>
20 20
   <supersededby>
21
-    <spec>JEP-0030</spec>
21
+    <spec>XEP-0030</spec>
22 22
   </supersededby>
23 23
   <shortname>iq-browse</shortname>
24 24
   &jer;
@@ -58,7 +58,7 @@
58 58
     <version>0.2</version>
59 59
     <date>2002-01-04</date>
60 60
     <initials>jkm</initials>
61
-    <remark>Updated to JEP format and revised description.</remark>
61
+    <remark>Updated to XML format and revised description.</remark>
62 62
   </revision>
63 63
   <revision>
64 64
     <version>0.1</version>
@@ -297,7 +297,7 @@
297 297
     </tr>
298 298
   </table>
299 299
   <p>Historically each category was used as the name of an element, and the type was an attribute, such as <![CDATA[<service type="aim"/>]]>. The proper expression for all new implementations supporting this specification is to express the type information as attributes on a generic item element: <![CDATA[<item category="service" type="aim"/>]]>. When processing returned browse information this new syntax should always be handled first, and the old syntax only used if it is important to be able to access older implementations.</p>
300
-  <p>Additional unofficial categories or types may be specified by prefixing their name with an "x-", such as "service/x-virgeim" or "x-location/gps". Changes to the official categories and subtypes may be defined either by revising this JEP or by activating another JEP. Removal of a category or subtype must be noted in this document.</p>
300
+  <p>Additional unofficial categories or types may be specified by prefixing their name with an "x-", such as "service/x-virgeim" or "x-location/gps". Changes to the official categories and subtypes may be defined either by revising this document or by activating another specification. Removal of a category or subtype must be noted in this document.</p>
301 301
 </section1>
302 302
 <section1 topic='The jabber:iq:browse Namespace'>
303 303
   <p>The namespace containing the Jabber Browsing data is jabber:iq:browse. The primary element within this namespace is 'item' (again, historically every category listed above would also be an element).</p>
@@ -422,10 +422,10 @@
422 422
   <p>There are no security features or concerns related to this proposal.</p>
423 423
 </section1>
424 424
 <section1 topic='IANA Considerations'>
425
-  <p>This JEP requires no interaction with &IANA;.</p>
425
+  <p>This document requires no interaction with &IANA;.</p>
426 426
 </section1>
427 427
 <section1 topic='XMPP Registrar Considerations'>
428
-  <p>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:iq:browse' is already a registered protocol namespace.</p>
428
+  <p>No action on the part of the &REGISTRAR; is necessary as a result of this document, since 'jabber:iq:browse' is already a registered protocol namespace.</p>
429 429
 </section1>
430 430
 <section1 topic='XML Schema'>
431 431
   <code><![CDATA[
@@ -468,6 +468,6 @@
468 468
     ]]></code>
469 469
 </section1>
470 470
 <section1 topic='Future Considerations'>
471
-  <p>The 'jabber:iq:browse' namespace has been in use for quite some time. However, live browsing still needs to be better defined by a generic publication/subscription system. It is assumed that when such a system is defined, updates to this JEP will be made. It is, however, possible that no futher changes to jabber:iq:browse itself may be needed.</p>
471
+  <p>The 'jabber:iq:browse' namespace has been in use for quite some time. However, live browsing still needs to be better defined by a generic publication/subscription system. It is assumed that when such a system is defined, updates to this document will be made. It is, however, possible that no futher changes to jabber:iq:browse itself may be needed.</p>
472 472
 </section1>
473 473
 </xep>

+ 1
- 1
xep-0012.xml View File

@@ -48,7 +48,7 @@
48 48
     <version>0.2</version>
49 49
     <date>2002-01-04</date>
50 50
     <initials>tjm</initials>
51
-    <remark>JEP form for standardization.</remark>
51
+    <remark>Converted to XML format.</remark>
52 52
   </revision>
53 53
   <revision>
54 54
     <version>0.1</version>

+ 1
- 1
xep-0014.xml View File

@@ -23,7 +23,7 @@
23 23
     <version>0.2</version>
24 24
     <date>2002-01-16</date>
25 25
     <initials>psa</initials>
26
-    <remark>First release to CVS, including editorial changes by the JEP Editor and assignment of JEP number.</remark>
26
+    <remark>First release to CVS, including editorial changes and assignment of number.</remark>
27 27
   </revision>
28 28
   <revision>
29 29
     <version>0.1</version>

+ 2
- 2
xep-0015.xml View File

@@ -29,7 +29,7 @@
29 29
       <version>0.3</version>
30 30
       <date>2002-04-16</date>
31 31
       <initials>cwc</initials>
32
-      <remark>Added more specific details to the protocol. Added more examples. Tried to make the whole JEP more readable.</remark>
32
+      <remark>Added more specific details to the protocol. Added more examples. Tried to make the whole document more readable.</remark>
33 33
     </revision>
34 34
     <revision>
35 35
       <version>0.2</version>
@@ -47,7 +47,7 @@
47 47
       <version>1.0</version>
48 48
       <date>2002-01-16</date>
49 49
       <initials>psa</initials>
50
-      <remark>First release to CVS, including editorial changes by the JEP Editor and assignment of JEP number.</remark>
50
+      <remark>First release to CVS, including editorial changes and assignment of number.</remark>
51 51
     </revision>
52 52
     <revision>
53 53
       <version>0.9</version>

+ 3
- 3
xep-0018.xml View File

@@ -127,9 +127,9 @@
127 127
     <p>There are no security features or concerns related to this proposal.</p>
128 128
   </section1>
129 129
   <section1 topic="IANA Considerations">
130
-    <p>No interaction with &IANA; is required as a result of this JEP.</p>
130
+    <p>No interaction with &IANA; is required as a result of this document.</p>
131 131
   </section1>
132
-  <section1 topic="Jabber Registrar Considerations">
133
-    <p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p>
132
+  <section1 topic="XMPP Registrar Considerations">
133
+    <p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
134 134
   </section1>
135 135
 </xep>

+ 15
- 15
xep-0019.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
   <title>Streamlining the JIGs</title>
10
-  <abstract>This JEP proposes to streamline the existing Jabber Interest Groups (JIGs).</abstract>
10
+  <abstract>This document proposes to streamline the existing Jabber Interest Groups (JIGs).</abstract>
11 11
   &LEGALNOTICE;
12 12
   <number>0019</number>
13 13
   <status>Active</status>
@@ -38,39 +38,39 @@
38 38
   </revision>
39 39
 </header>
40 40
 <section1 topic="Introduction">
41
-  <p>The Jabber Software Foundation is an experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this JEP, I argue that just such an adjustment is now necessary with regard to the Jabber Interest Groups (JIGs). <note>The proposal contained in this JEP formalizes some conclusions reached during a weekly discussion forum held by the Jabber Software Foundation on 2002-01-23. A log of that discussion is available at <link url="http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html">http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html</link>. Further discussion within the Standards JIG has been helpful in clarifying the argument presented here.</note></p>
41
+  <p>The Jabber Software Foundation is an experiment. When we initially set up our policies, processes, and structures, we knew that our initial thoughts might not be our final thoughts, and that we would need to make adjustments as experience dictated. In this document, I argue that just such an adjustment is now necessary with regard to the Jabber Interest Groups (JIGs). <note>The proposal contained in this document formalizes some conclusions reached during a weekly discussion forum held by the Jabber Software Foundation on 2002-01-23. A log of that discussion is available at <link url="http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html">http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-01-23.html</link>. Further discussion within the Standards JIG has been helpful in clarifying the argument presented here.</note></p>
42 42
 </section1>
43 43
 <section1 topic="The Problem">
44
-  <p>&xep0002; defined a JIG as "a working group approved by the Jabber Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a JIG is to "produce acceptable enhancements to the Jabber protocol (delivered in the form of Jabber Enhancement Proposals or JEPs) within a reasonably limited period of time". In early January of 2002, JEP-0002 was modified to incorporate language about disbanding a JIG after a defined period of inactivity on the JIG's mailing list (normally six months).</p>
45
-  <p>Unfortunately, it is widely recognized in the Jabber community that the JIGs are not working. Ten JIGs have been approved by the Jabber Council,<note>See <link url='http://www.jabber.org/jigs.html'>http://www.jabber.org/jigs.html</link> for the official list.</note> eight of them over six months ago in July and August of 2001. Two of the special-purpose JIGs (OOB and Presence) have seen no activity whatsoever and thus are clearly eligible to be disbanded. The other special-purpose JIGs (Conference, Formatting, Forms, Profiles, RPC, and Whiteboard) have seen extremely limited activity and it is a judgment call whether some of them should be allowed to continue according to the current standards defined in JEP-0002. Only the two "standing" JIGs (Security and Standards) have experienced significant and continued mailing list activity, mainly because the Standards JIG has assumed the role of discussion forum for JEPs before they are submitted to the Jabber Council.</p>
46
-  <p>In perhaps the best measure of success or failure, only one JIG has produced a JEP for submission to the Jabber Council, and that JEP (&xep0009;) was essentially created outside the JIG structure at JabberCon 2001. Perhaps most ominously, no other JIG has shown any signs of progress toward completing a JEP, or even starting work on one. With the possible exception of JEP-0009, all of the JEPs created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the JIGs.</p>
44
+  <p>&xep0002; defined a JIG as "a working group approved by the Jabber Council to address specific areas of growth or concern within the Jabber community", and specified that the function of a JIG is to "produce acceptable enhancements to the Jabber protocol within a reasonably limited period of time". In early January of 2002, XEP-0002 was modified to incorporate language about disbanding a JIG after a defined period of inactivity on the JIG's mailing list (normally six months).</p>
45
+  <p>Unfortunately, it is widely recognized in the Jabber community that the JIGs are not working. Ten JIGs have been approved by the Jabber Council,<note>See <link url='http://www.jabber.org/jigs.html'>http://www.jabber.org/jigs.html</link> for the official list.</note> eight of them over six months ago in July and August of 2001. Two of the special-purpose JIGs (OOB and Presence) have seen no activity whatsoever and thus are clearly eligible to be disbanded. The other special-purpose JIGs (Conference, Formatting, Forms, Profiles, RPC, and Whiteboard) have seen extremely limited activity and it is a judgment call whether some of them should be allowed to continue according to the current standards defined in XEP-0002. Only the two "standing" JIGs (Security and Standards) have experienced significant and continued mailing list activity, mainly because the Standards JIG has assumed the role of discussion forum for specifications before they are submitted to the Jabber Council.</p>
46
+  <p>In perhaps the best measure of success or failure, only one JIG has produced a specification for submission to the Jabber Council, and that specification (&xep0009;) was essentially created outside the JIG structure at JabberCon 2001. Perhaps most ominously, no other JIG has shown any signs of progress toward completing a specification, or even starting work on one. With the possible exception of XEP-0009, all of the specifications created so far have come from individuals or small, ad-hoc groups -- not through the efforts of the JIGs.</p>
47 47
   <p>In other words, an honest assessment forces us to conclude that the JIGs are not working.</p>
48 48
 </section1>
49 49
 <section1 topic="Analysis and Possible Solutions">
50 50
   <p>I see several possible solutions to the JIG problem:</p>
51 51
   <ol>
52
-    <li>"Crack the whip" -- encourage and cajole the existing JIGs into becoming more active, and energetically manage them so that they produce JEPs.</li>
52
+    <li>"Crack the whip" -- encourage and cajole the existing JIGs into becoming more active, and energetically manage them so that they produce specifications.</li>
53 53
     <li>"Wait and see" -- immediately disband the JIGs that are clearly inactive but keep the existing JIGs and hope that they will eventually produce something of value (over time disbanding any that are conspicuously inactive).</li>
54 54
     <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 the Jabber protocols.</li>  
55 55
   </ol>
56 56
   <p>Given the lack of activity in the JIGs 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 JIGs 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 JIGs and find a better way of working.</p>
57
-  <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 JIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good Jabber-based software. Nor do I think it's that members of the Jabber community are incapable of creating JEPs, because individually and in small, ad-hoc groups they have created quite a few.</p>
57
+  <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 JIG members are lazy, stupid, or incompetent -- after all, these are the same people who have in many instances created good Jabber-based software. Nor do I think it's that members of the Jabber community are incapable of creating specifications, because individually and in small, ad-hoc groups they have created quite a few.</p>
58 58
   <p>I see several reasons why the JIGs are not working:</p>
59 59
   <ol>
60 60
     <li>The Jabber community right now is too small to be split up successfully into smaller interest groups.</li>
61 61
     <li>We have tried to overlay too much structure too quickly. Jabber has traditionally been a fairly anarchic project (or set of projects), and creating ten JIGs right away was at odds with that successful lack of structure.</li>
62
-    <li>Good JEPs, like good software programs, are usually created by at most a few interested people, not a formal group. Formal groups are not needed to move Jabber forward.</li>
62
+    <li>Good specifications, like good software programs, are usually created by at most a few interested people, not a formal group. Formal groups are not needed to move Jabber forward.</li>
63 63
   </ol>
64
-  <p>If we reflect on what is working, we see that JEPs are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards JIG, which contains everyone who is strongly interested in the Jabber protocols. Finally, we notice that the special-purpose JIGs have not played any appreciable role in our success so far.</p>
64
+  <p>If we reflect on what is working, we see that specifications are being produced by individuals and small, ad-hoc groups. We also see that active discussion of those proposals is taking place in the Standards JIG, which contains everyone who is strongly interested in the Jabber protocols. Finally, we notice that the special-purpose JIGs have not played any appreciable role in our success so far.</p>
65 65
 </section1>
66 66
 <section1 topic="Proposed Solution">
67
-  <p>My proposed solution takes into account everything we have learned to date about producing JEPs and advancing the state of the Jabber protocols. Specifically, I propose that we take the following steps:</p>
67
+  <p>My proposed solution takes into account everything we have learned to date about producing specifications and advancing the state of the Jabber protocols. Specifically, I propose that we take the following steps:</p>
68 68
   <ol>
69
-    <li>Immediately disband all but the Standards JIG. <note>In an earlier version of this JEP, I proposed that we retain the Security JIG. However, since there is a security aspect to all protocols, I now think it is best if security-related topics are discussed within the Standards JIG, not in a separate Security JIG.</note></li>
70
-    <li>Rely on individuals and small, ad-hoc groups to create JEPs.</li>
71
-    <li>Continue to use the Standards JIG as the preferred forum for discussion of experimental JEPs before they are submitted to the Jabber Council.</li>
72
-    <li>If the Standards JIG cannot reach a working consensus on a given topic, let the JEP author(s) continue to rework their proposal informally outside the context of the Standards JIG. <note>One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, <link url="http://www.jabberstudio.org/">http://www.jabberstudio.org/</link>). Unlike the current JIGs, such a list would be established on the initiative of the JEP author(s) and would not require any formal approval by the Jabber Council.</note></li>
69
+    <li>Immediately disband all but the Standards JIG. <note>In an earlier version of this document, I proposed that we retain the Security JIG. However, since there is a security aspect to all protocols, I now think it is best if security-related topics are discussed within the Standards JIG, not in a separate Security JIG.</note></li>
70
+    <li>Rely on individuals and small, ad-hoc groups to create specifications.</li>
71
+    <li>Continue to use the Standards JIG as the preferred forum for discussion of experimental specifications before they are submitted to the Jabber Council.</li>
72
+    <li>If the Standards JIG cannot reach a working consensus on a given topic, let the document author(s) continue to rework their proposal informally outside the context of the Standards JIG. <note>One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, <link url="http://www.jabberstudio.org/">http://www.jabberstudio.org/</link>). Unlike the current JIGs, such a list would be established on the initiative of the document author(s) and would not require any formal approval by the Jabber Council.</note></li>
73 73
   </ol>
74
-  <p>There may be value in bringing back specialized JIGs in the future when the Jabber community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this JEP. <note>Lest there be any concern that disbanding the JIGs is outside the power or purview of the Jabber Council, I note that Section 8.2 of the Bylaws of the Jabber Software Foundation states in part that "The Jabber Council or the Members of the Corporation may, by resolution, ... terminate a Jabber Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at <link url="http://www.jabber.org/bylaws.html">http://www.jabber.org/bylaws.html</link>.)</note></p>
74
+  <p>There may be value in bringing back specialized JIGs in the future when the Jabber community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. <note>Lest there be any concern that disbanding the JIGs is outside the power or purview of the Jabber Council, I note that Section 8.2 of the Bylaws of the Jabber Software Foundation states in part that "The Jabber Council or the Members of the Corporation may, by resolution, ... terminate a Jabber Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at <link url="http://www.jabber.org/bylaws.html">http://www.jabber.org/bylaws.html</link>.)</note></p>
75 75
 </section1>
76 76
 </xep>

+ 2
- 2
xep-0021.xml View File

@@ -16,7 +16,7 @@
16 16
   <type>Standards Track</type>
17 17
   <jig>Standards</jig>
18 18
   <supersedes>None</supersedes>
19
-  <supersededby>JEP-0060</supersededby>
19
+  <supersededby>XEP-0060</supersededby>
20 20
   <shortname>None</shortname>
21 21
   <author>
22 22
     <firstname>Robert</firstname>
@@ -28,7 +28,7 @@
28 28
     <version>0.2</version>
29 29
     <date>2003-04-22</date>
30 30
     <initials>psa</initials>
31
-    <remark>At the request of the author, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0060. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
31
+    <remark>At the request of the author, the status of this document has been changed to Retracted since it has been superseded by XEP-0060. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
32 32
   </revision>
33 33
   <revision>
34 34
     <version>0.1</version>

+ 2
- 2
xep-0022.xml View File

@@ -270,7 +270,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
270 270
 <section1 topic='IANA Considerations'>
271 271
   <p>This document requires no interaction with &IANA;.</p>
272 272
 </section1>
273
-<section1 topic='Jabber Registrar Considerations'>
273
+<section1 topic='XMPP Registrar Considerations'>
274 274
   <p>No action on the part of the &REGISTRAR; is necessary as a result of this document, since 'jabber:x:event' is already a registered protocol namespace.</p>
275 275
 </section1>
276 276
 
@@ -315,7 +315,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
315 315
 
316 316
 <section1 topic='Open Issues'>
317 317
   <ol>
318
-    <li>In a Standards Track JEP addressing event functionality, it would be desirable to have more cancellation methods for composing events than those defined in this Informational JEP. For instance, is someone still composing if they become unavailable? This example points to the fact that cancellation of a composing event can either be explicit (the default or desired scenario) or implicit (e.g., through a change in the availability state of a client or the existence of the session associated with the message composition).</li>
318
+    <li>In a Standards Track specification addressing event functionality, it would be desirable to have more cancellation methods for composing events than those defined in this Informational document. For instance, is someone still composing if they become unavailable? This example points to the fact that cancellation of a composing event can either be explicit (the default or desired scenario) or implicit (e.g., through a change in the availability state of a client or the existence of the session associated with the message composition).</li>
319 319
   </ol>
320 320
 </section1>
321 321
 

+ 6
- 6
xep-0023.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
   <title>Message Expiration</title>
10
-  <abstract>This specification documents an historical protocol that was used to specify expiration dates for messages; this protocol has been deprecated in favor of JEP-0079: Advanced Message Processing.</abstract>
10
+  <abstract>This specification documents an historical protocol that was used to specify expiration dates for messages; this protocol has been deprecated in favor of XEP-0079: Advanced Message Processing.</abstract>
11 11
   &LEGALNOTICE;
12 12
   <number>0023</number>
13 13
   <status>Deprecated</status>
@@ -18,7 +18,7 @@
18 18
   </dependencies>
19 19
   <supersedes/>
20 20
   <supersededby>
21
-    <spec>JEP-0079</spec>
21
+    <spec>XEP-0079</spec>
22 22
   </supersededby>
23 23
   <shortname>x-expire</shortname>
24 24
   <schemaloc>
@@ -41,7 +41,7 @@
41 41
     <version>1.2</version>
42 42
     <date>2004-10-18</date>
43 43
     <initials>psa</initials>
44
-    <remark>Per a vote of the Jabber Council, changed status to Deprecated since message expiration functionality should be implemented via JEP-0079: Advanced Message Processing.</remark>
44
+    <remark>Per a vote of the Jabber Council, changed status to Deprecated since message expiration functionality should be implemented via XEP-0079: Advanced Message Processing.</remark>
45 45
   </revision>
46 46
   <revision>
47 47
     <version>1.1</version>
@@ -121,10 +121,10 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
121 121
   <p>There are no security features or concerns related to this proposal.</p>
122 122
 </section1>
123 123
 <section1 topic='IANA Considerations'>
124
-  <p>This JEP requires no interaction with &IANA;.</p>
124
+  <p>This document requires no interaction with &IANA;.</p>
125 125
 </section1>
126 126
 <section1 topic='XMPP Registrar Considerations'>
127
-  <p>No action on the part of the &REGISTRAR; is necessary as a result of this JEP, since 'jabber:x:expire' is already a registered protocol namespace.</p>
127
+  <p>No action on the part of the &REGISTRAR; is necessary as a result of this document, since 'jabber:x:expire' is already a registered protocol namespace.</p>
128 128
 </section1>
129 129
 
130 130
 <section1 topic='XML Schema'>
@@ -168,7 +168,7 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
168 168
 <section1 topic='Open Issues'>
169 169
   <ol>
170 170
     <li>The jabber:x:expire namespace is processed only for delayed messages and only by servers and subsystems which support this informational draft. Therefore it is possible or even likely that a TTL will not be properly handled from the user perspective.</li>
171
-    <li>A physical, time-based TTL is not implemented by this JEP, and would not be possible across systems without synchronized time.</li>
171
+    <li>A physical, time-based TTL is not implemented by this document, and would not be possible across systems without synchronized time.</li>
172 172
   </ol>
173 173
 </section1>
174 174
 

+ 2
- 2
xep-0024.xml View File

@@ -14,7 +14,7 @@
14 14
   <type>Standards Track</type>
15 15
   <jig>Standards</jig>
16 16
   <supersedes>None</supersedes>
17
-  <supersededby>JEP-0060</supersededby>
17
+  <supersededby>XEP-0060</supersededby>
18 18
   <shortname>None</shortname>
19 19
   <author>
20 20
     <firstname>DJ</firstname>
@@ -32,7 +32,7 @@
32 32
     <version>0.2</version>
33 33
     <date>2003-04-22</date>
34 34
     <initials>psa</initials>
35
-    <remark>At the request of the authors, the status of this JEP has been changed to Retracted since it has been superseded by JEP-0060. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
35
+    <remark>At the request of the authors, the status of this document has been changed to Retracted since it has been superseded by XEP-0060. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
36 36
   </revision>
37 37
   <revision>
38 38
     <version>0.1</version>

+ 1
- 1
xep-0025.xml View File

@@ -18,7 +18,7 @@
18 18
     </dependencies>
19 19
     <supersedes/>
20 20
     <supersededby>
21
-      <spec>JEP-0124</spec>
21
+      <spec>XEP-0124</spec>
22 22
     </supersededby>
23 23
     <shortname>httppoll</shortname>
24 24
     &hildjj;

+ 8
- 8
xep-0026.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
 	<title>Internationalization (I18N)</title>
10
-        <abstract>NOTE WELL: this JEP was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
10
+        <abstract>NOTE WELL: this document was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
11 11
         &LEGALNOTICE;
12 12
 	<number>0026</number>
13 13
 	<status>Retracted</status>
@@ -27,7 +27,7 @@
27 27
           <version>0.2</version>
28 28
           <date>2003-11-05</date>
29 29
           <initials>psa</initials>
30
-          <remark>The status of this JEP has been changed to Retracted since it has been superseded by &xmppcore;. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
30
+          <remark>The status of this document has been changed to Retracted since it has been superseded by &xmppcore;. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
31 31
         </revision>
32 32
 	<revision>
33 33
 		<version>0.1</version>
@@ -86,20 +86,20 @@
86 86
   &lt;body'&gt;Ich bin ein Berliner!&lt;/body'&gt;
87 87
 &lt;/message&gt;  </example>
88 88
 		<p>
89
-			An xml:lang tag can be put onto any XML element; for the purposes of this JEP, 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;.
89
+			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;.
90 90
 		</p>
91 91
 	</section2>
92 92
 	
93 93
 	<section2 topic='Client support'>
94 94
 		<p>
95
-			A client claiming to support this JEP has to initiate server connection slightly differently by putting an xml:lang attribute in the initial &lt;stream:stream&gt; element.
95
+			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.
96 96
 		</p>
97 97
 		<example caption='Jabber session initiated with Canadian French as default'>
98 98
 &lt;?xml version="1.0" encoding="UTF-8" ?&gt;
99 99
 &lt;stream:stream to='jabber.org' xmlns='jabber:client'
100 100
           xmlns:stream='http://etherx.jabber.org/streams' xml:lang='fr-CA'&gt; </example>
101 101
 		<p>
102
-			Servers not supporting this JEP will just ignore the additional attribute. Compliant server can be distinguished by the fact that their reply &lt;stream:stream&gt; element also contains an xml:lang attribute, indicating the main language of the server. A compliant client has to detect whether the server is compliant or not, and base its future behavior on this information.
102
+			Servers not supporting this document will just ignore the additional attribute. Compliant server can be distinguished by the fact that their reply &lt;stream:stream&gt; element also contains an xml:lang attribute, indicating the main language of the server. A compliant client has to detect whether the server is compliant or not, and base its future behavior on this information.
103 103
 		</p>
104 104
 		<example caption='Reply by an English-language Jabber server'>
105 105
 &lt;stream:stream from='jabber.org' id='12345' xmlns='jabber:client'
@@ -108,7 +108,7 @@
108 108
 			If the client thus determines that the server is compliant, then it doesn't have to do anything beyond this point. All its outgoing messages will automatically be flagged by the server with an xml:lang attribute if necessary. Thus writing a minimal compliant client is trivial.
109 109
 		</p>
110 110
 		<p>
111
-			If it is determined that the server does not support this JEP, and the client still wants to offer locale support, it may start flagging all its outgoing message/iq/presence elements with the xml:lang attribute, to ensure that other components/clients which do conform to this JEP can handle the localization despite the local server not doing so.
111
+			If it is determined that the server does not support this document, and the client still wants to offer locale support, it may start flagging all its outgoing message/iq/presence elements with the xml:lang attribute, to ensure that other components/clients which do conform to this document can handle the localization despite the local server not doing so.
112 112
 		</p>
113 113
 		<p>
114 114
 			Finally, if for whatever reasons the client wants to flag particular messages with a different locale (e.g. if the user is bilingual), it can do so at any time by putting an appropriate xml:lang element in the outgoing data. This will override the previously set default locale for this message only.
@@ -121,7 +121,7 @@
121 121
 			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. 
122 122
 		</p>
123 123
 		<p>
124
-			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 JEP.
124
+			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.
125 125
 		</p>
126 126
 		<p>
127 127
 			The server should not only allow user clients to specify a default language this way, but also server-side components, like the JUD should be allowed to do this.
@@ -137,7 +137,7 @@
137 137
 	
138 138
 	<section2 topic='Service support'>
139 139
 		<p>
140
-			Jabber based services that wish to comply to this JEP 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>JEP-0004</cite>.
140
+			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>.
141 141
 		</p>
142 142
 		<example caption='Search form in English'>
143 143
 &lt;iq from='users.jabber.org' type='result' id='4' xml:lang='en'&gt;

+ 4
- 4
xep-0029.xml View File

@@ -27,7 +27,7 @@
27 27
             <version>1.1</version>
28 28
             <date>2003-10-03</date>
29 29
             <initials>psa</initials>
30
-            <remark>Changed status to Retracted. This JEP is superseded by the XMPP Core memo defined by the IETF's XMPP Working Group.</remark>
30
+            <remark>Changed status to Retracted. This document is superseded by the XMPP Core memo defined by the IETF's XMPP Working Group.</remark>
31 31
         </revision>
32 32
         <revision>
33 33
             <version>1.0</version>
@@ -51,7 +51,7 @@
51 51
         </revision>
52 52
     </header>
53 53
     <section1 topic='Introduction'>
54
-        <p>Jabber Identifiers (JIDs) uniquely identify individual entities in the Jabber network. To date, their syntax has been defined by convention, existing implementations, and available documentation. As it exists, certain characters that are allowed in JIDs cause ambiguity, and the lack of a size limit on resources defies database schemas and causes some trivial JID operations to require dynamic memory allocation. This JEP seeks to both define and improve the existing JID syntax. This JEP will not explain the general usage or nature of JIDs, instead focusing on syntax.</p>
54
+        <p>Jabber Identifiers (JIDs) uniquely identify individual entities in the Jabber network. To date, their syntax has been defined by convention, existing implementations, and available documentation. As it exists, certain characters that are allowed in JIDs cause ambiguity, and the lack of a size limit on resources defies database schemas and causes some trivial JID operations to require dynamic memory allocation. This document seeks to both define and improve the existing JID syntax. This document will not explain the general usage or nature of JIDs, instead focusing on syntax.</p>
55 55
     </section1>
56 56
     <section1 topic='JIDs'>
57 57
         <p>JIDs consist of three main parts:</p>
@@ -104,14 +104,14 @@
104 104
             <p>Resources identifiers are case-sensitive and are limited to 256 bytes. They may include any Unicode character greater than #x20, except #xFFFE and #xFFFF.</p>
105 105
         </section2>
106 106
         <section2 topic='Limited Resources'>
107
-            <p>To date, resource identifiers have not had a fixed limit on their length.  This JEP seeks to limit it to 256 bytes for the following reasons:</p>
107
+            <p>To date, resource identifiers have not had a fixed limit on their length.  This document seeks to limit it to 256 bytes for the following reasons:</p>
108 108
             <ol>
109 109
                 <li>In order to perform JID manipulations safely, one cannot use stack space if there is no limit.  This forces temporary calculations onto the heap which is unnecessarily costly.</li>
110 110
                 <li>As a fixed length character field, a resource identifier is more easily stored in, searched on, and retrieved from a database.  If an end user may store an encyclopedia's worth of information in their resource, then the only way it can be stored without truncating it is to store it as a large object (BLOB or CLOB).  Depending on the database used, that makes it either grossly inefficient or impossible to search on.</li>
111 111
                 <li>There exist denial of service attacks stemming from an unlimited resource length.</li>
112 112
             </ol>
113 113
             <p>In a worst-case encoding, such as Han ideographs, 256 bytes will provide enough storage space for 64 character points.  This provides a lower bound on the number of characters a node may have in its resource.</p>
114
-            <p>Specifying limits in terms of bytes instead of characters is somewhat arbitrary once a lower bound for characters is established.  This JEP proposes limits in terms of bytes mainly because doing so results in parsing efficiency; specifically, an implementation does not have to un-encode the UTF-8 string for the sole purpose of further restricting character sets that require fewer than four bytes per character point.  It is sufficient to have a lower bound on characters and an upper bound on bytes.</p>
114
+            <p>Specifying limits in terms of bytes instead of characters is somewhat arbitrary once a lower bound for characters is established.  This document proposes limits in terms of bytes mainly because doing so results in parsing efficiency; specifically, an implementation does not have to un-encode the UTF-8 string for the sole purpose of further restricting character sets that require fewer than four bytes per character point.  It is sufficient to have a lower bound on characters and an upper bound on bytes.</p>
115 115
         </section2>
116 116
     </section1>
117 117
 </xep>

+ 1
- 1
xep-0032.xml View File

@@ -22,7 +22,7 @@
22 22
     <version>0.4</version>
23 23
     <date>2003-09-02</date>
24 24
     <initials>psa</initials>
25
-    <remark>Retracted the JEP, since it is superseded by draft-ietf-xmpp-uri, an Internet-Draft produced by the IETF's XMPP WG.</remark>
25
+    <remark>Retracted the document, since it is superseded by draft-ietf-xmpp-uri, an Internet-Draft produced by the IETF's XMPP WG.</remark>
26 26
   </revision>
27 27
   <revision>
28 28
     <version>0.3</version>

+ 3
- 3
xep-0035.xml View File

@@ -9,7 +9,7 @@
9 9
 
10 10
 <header>
11 11
   <title>SSL/TLS Integration</title>
12
-  <abstract>NOTE WELL: this JEP was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
12
+  <abstract>NOTE WELL: this specification was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
13 13
   &LEGALNOTICE;
14 14
   <number>0035</number>
15 15
   <status>Retracted</status>
@@ -29,7 +29,7 @@
29 29
     <version>0.2</version>
30 30
     <date>2003-11-05</date>
31 31
     <initials>psa</initials>
32
-    <remark>The status of this JEP has been changed to Retracted since it has been superseded by &xmppcore;. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
32
+    <remark>The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
33 33
   </revision>
34 34
   <revision>
35 35
     <version>0.1</version>
@@ -121,7 +121,7 @@ S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
121 121
 <section1 topic="Certificate-based authentication">
122 122
   <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>
123 123
 
124
-  <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>JEP-0034</cite> for more information.</p>
124
+  <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>
125 125
   
126 126
   <p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
127 127
 </section1>

+ 1
- 1
xep-0037.xml View File

@@ -52,7 +52,7 @@
52 52
     <version>Version 0.4</version>
53 53
     <date>2002-07-11</date>
54 54
     <initials>lw</initials>
55
-    <remark>Reformatted to JEP XML.</remark>
55
+    <remark>Converted to XML format.</remark>
56 56
   </revision>
57 57
   <revision>
58 58
     <version>Version 0.3</version>

+ 1
- 1
xep-0038.xml View File

@@ -232,7 +232,7 @@
232 232
   <p>Also, this specification uses other MIME types that are maintained by IANA for the object and xml files that are included in the icon style packages.</p>
233 233
 </section1>
234 234
 
235
-<section1 topic='Jabber Registrar Considerations'>
235
+<section1 topic='XMPP Registrar Considerations'>
236 236
   <p>JANA shall register the namespace <tt>http://jabber.org/protocol/icon-styles</tt> as an official feature category.</p>
237 237
   <p>Also, JANA may choose to define IM-specific <tt>xml:lang</tt> "language codes" for use within Jabber (in addition to those defined in the XML specification). Such language codes would allow Jabber developers to support icons from MSN, Yahoo, and popular web message programs.</p>
238 238
 </section1>

+ 1
- 2
xep-0039.xml View File

@@ -128,8 +128,7 @@
128 128
       <version>0.1.4</version>
129 129
       <date>2002-07-23</date>
130 130
       <initials>rkd</initials>
131
-      <remark>Converted to XML as per JEP spec in preparation for
132
-      submission as experimental JEP.</remark>
131
+      <remark>Converted to XML format.</remark>
133 132
     </revision>
134 133
     <revision>
135 134
       <version>0.1.3</version>

+ 4
- 4
xep-0042.xml View File

@@ -13,9 +13,9 @@
13 13
   <status>Retracted</status>
14 14
   <type>Standards Track</type>
15 15
   <jig>Standards</jig>
16
-  <dependencies>JEP-0004 (OPTIONAL), JEP-0011 (RECOMMENDED) JEP-0029 (REQUIRED)</dependencies>
16
+  <dependencies>XEP-0004 (OPTIONAL), XEP-0011 (RECOMMENDED) XEP-0029 (REQUIRED)</dependencies>
17 17
   <supersedes>None</supersedes>
18
-  <supersededby>JEP-0065</supersededby>
18
+  <supersededby>XEP-0065</supersededby>
19 19
   <shortname>JOBS</shortname>
20 20
   <author>
21 21
     <firstname>Matthew</firstname>
@@ -27,7 +27,7 @@
27 27
     <version>0.5</version>
28 28
     <date>2003-04-11</date>
29 29
     <initials>psa</initials>
30
-    <remark>At the request of the JEP author, changed status to Retracted. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
30
+    <remark>At the request of the author, changed status to Retracted. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
31 31
   </revision>
32 32
   <revision>
33 33
     <version>0.4</version>
@@ -58,7 +58,7 @@
58 58
   <section2 topic='Introduction'>
59 59
     <p>Distributing data out-of-band (OOB) to one or more end-points is a requirement for many Jabber clients. The Jabber OOB Broadcast Service (JOBS) is a mechanism to allow end-points to open uni-directional data streams between each other, on top of which any number of applications can be built <note>Possible applications include file transfer, audio/video streaming, and some gaming implementations.</note>.</p>
60 60
 
61
-    <p>The aim of this JEP is to define a process of connecting a sender to one or more receivers through a secondary TCP port.</p>
61
+    <p>The aim of this document is to define a process of connecting a sender to one or more receivers through a secondary TCP port.</p>
62 62
   </section2>
63 63
   <section2 topic='Design Concepts'>
64 64
     <p>As the name implies, JOBS is designed to enable multicast, uni-directional OOB connections. These connections are usually between a "sender" client, a JOBS "service", and one or more "receiver" clients. Each such set of connections is collectively called a session. JOBS is designed to allow a single service to handle multiple sessions over a single host/port combination.</p>

+ 4
- 4
xep-0043.xml View File

@@ -39,27 +39,27 @@
39 39
     simple mechanism for a JID to read/write data that it has access to 
40 40
     and specifying a model for those schemas to use in xml.</p>
41 41
   
42
-    <p>This JEP has two aims.</p>
42
+    <p>This document has two aims.</p>
43 43
 
44 44
     <ol>
45 45
       <li>Be able to request the available schemas</li>
46 46
       <li>Perform near SQL-like data manipulation</li>
47 47
     </ol>
48 48
   
49
-    <p>Although designed for use with an RDBMS this JEP is not
49
+    <p>Although designed for use with an RDBMS this document is not
50 50
     restricted to such uses. It may be used with any data storage 
51 51
     system that can be broken down to a simple table, column/row 
52 52
     format. for example comma delimited files.</p>
53 53
   </section1>
54 54
   <section1 topic='Prerequisites'>
55
-    <p>To understand the following sections of this JEP the reader
55
+    <p>To understand the following sections of this document the reader
56 56
     must be aware of the following.</p>
57 57
 
58 58
     <section2 topic='Namespace'>
59 59
       <p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link> 
60 60
       will be used until this becomes a jep. Once officially accepted as
61 61
       a jep and approved as final by the council, it will become 
62
-      <link>http://www.jabber.org/jeps/jep-0043.html</link>.</p>
62
+      <link>http://www.xmpp.org/extensions/xep-0043.html</link>.</p>
63 63
     </section2>
64 64
     <section2 topic='Elements'>
65 65
       <ul>

+ 2
- 2
xep-0045.xml View File

@@ -207,7 +207,7 @@
207 207
     <version>0.23</version>
208 208
     <date>2002-11-06</date>
209 209
     <initials>psa</initials>
210
-    <remark><p>Added examples for disco#items queries sent to a room; prohibited 'type' attribute on invite messages sent from client to room; added dependencies for JEPs 11 and 30; changed 'room user' to 'occupant'; fixed many small errors throughout.</p></remark>
210
+    <remark><p>Added examples for disco#items queries sent to a room; prohibited 'type' attribute on invite messages sent from client to room; added dependencies on browse and disco; changed 'room user' to 'occupant'; fixed many small errors throughout.</p></remark>
211 211
   </revision>
212 212
   <revision>
213 213
     <version>0.22</version>
@@ -351,7 +351,7 @@
351 351
     <version>0.5.1</version>
352 352
     <date>2002-09-20</date>
353 353
     <initials>psa</initials>
354
-    <remark><p>Added DTDs; changed feature discovery to use &lt;x/&gt; element rather than query and made service response come in IQ result; fixed reference to JEP 29; changed 'grant' to 'add' and 'revoke' to 'remove' for consistency in the item attributes; made several other small changes.</p></remark>
354
+    <remark><p>Added DTDs; changed feature discovery to use &lt;x/&gt; element rather than query and made service response come in IQ result; fixed reference to JID spec; changed 'grant' to 'add' and 'revoke' to 'remove' for consistency in the item attributes; made several other small changes.</p></remark>
355 355
   </revision>
356 356
   <revision>
357 357
     <version>0.5</version>

+ 1
- 1
xep-0051.xml View File

@@ -31,7 +31,7 @@
31 31
     <version>0.1</version>
32 32
     <date>2002-10-08</date>
33 33
     <initials>psa</initials>
34
-    <remark>Initial release as a JEP.</remark>
34
+    <remark>Initial version.</remark>
35 35
   </revision>
36 36
   <revision>
37 37
     <version>0.0.2</version>

+ 1
- 1
xep-0052.xml View File

@@ -63,7 +63,7 @@
63 63
 
64 64
 <section1 topic='Use Cases'>
65 65
   <p>
66
-    This document covers one use case of sending a file to another user.  Future JEPs
66
+    This document covers one use case of sending a file to another user.  Future specifications
67 67
     may enhance this to include searching and offering.
68 68
   </p>
69 69
 

+ 5
- 5
xep-0055.xml View File

@@ -15,7 +15,7 @@
15 15
   <jig>Standards JIG</jig>
16 16
   <dependencies>
17 17
     <spec>XMPP Core</spec>
18
-    <spec dep="SHOULD">JEP-0004</spec>
18
+    <spec dep="SHOULD">XEP-0004</spec>
19 19
   </dependencies>
20 20
   <supersedes/>
21 21
   <supersededby/>
@@ -132,7 +132,7 @@
132 132
   </section2>
133 133
 </section1>
134 134
 <section1 topic='Extensibility' anchor='extensibility'>
135
-  <p>The fields defined in the 'jabber:iq:search' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, <strong>Data Forms</strong> SHOULD be used; a host MUST NOT add new fields to the 'jabber:iq:search' namespace. Support for extensibility via <strong>Data Forms</strong> is RECOMMENDED, but is not required for compliance with this JEP.</p>
135
+  <p>The fields defined in the 'jabber:iq:search' namespace are strictly limited to those specified in the schema. If a host needs to gather additional information, <strong>Data Forms</strong> SHOULD be used; a host MUST NOT add new fields to the 'jabber:iq:search' namespace. Support for extensibility via <strong>Data Forms</strong> is RECOMMENDED, but is not required for compliance with this document.</p>
136 136
   <p>The extensibility mechanism for searching makes use of a hidden FORM_TYPE field for the purpose of standardizing field names within the form, as defined in &xep0068;. Implementations supporting this extensibility mechanism SHOULD support field standardization as well.</p>
137 137
   <example caption='Entity Requests Search Fields from Service'><![CDATA[
138 138
 <iq type='get'
@@ -239,7 +239,7 @@
239 239
   <p>There are no security features or concerns related to this proposal.</p>
240 240
 </section1>
241 241
 <section1 topic='IANA Considerations' anchor='iana'>
242
-  <p>This JEP requires no interaction with &IANA;.</p>
242
+  <p>This document requires no interaction with &IANA;.</p>
243 243
 </section1>
244 244
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
245 245
   <p>The &REGISTRAR; shall include the following information in its registries.</p>
@@ -247,11 +247,11 @@
247 247
     <p>The XMPP Registrar includes the 'jabber:iq:search' namespace in its registry of protocol namespaces.</p>
248 248
   </section2>
249 249
   <section2 topic='Field Standardization' anchor='registrar-formtypes'>
250
-    <p>The following fields are reserved for use within jabber:x:data forms scoped by a FORM_TYPE of 'jabber:iq:search'; additional fields MAY be added via the XMPP Registrar's normal registration process but are outside the scope of this JEP.</p>
250
+    <p>The following fields are reserved for use within jabber:x:data forms scoped by a FORM_TYPE of 'jabber:iq:search'; additional fields MAY be added via the XMPP Registrar's normal registration process but are outside the scope of this document.</p>
251 251
     <code caption='Registry Submission'><![CDATA[
252 252
 <form_type>
253 253
   <name>jabber:iq:search</name>
254
-  <doc>JEP-0055</doc>
254
+  <doc>XEP-0055</doc>
255 255
   <desc>Forms enabling directory searches.</desc>
256 256
   <field
257 257
       var='first'

+ 3
- 3
xep-0057.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
   <header>
9 9
     <title>Extended Roster</title>
10
-    <abstract>This JEP defines a way to handle extended roster items.</abstract> 
10
+    <abstract>This document defines a way to handle extended roster items.</abstract> 
11 11
     &LEGALNOTICE;
12 12
     <number>0057</number>
13 13
     <status>Retracted</status>
@@ -26,7 +26,7 @@
26 26
       <version>0.2</version>
27 27
       <date>2003-04-28</date>
28 28
       <initials>psa</initials>
29
-      <remark>Changed the status to Retracted at the request of the author, since the proposed protocol was incompatible with XMPP and clients have begun using jabber:iq:private for this kind of functionality. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
29
+      <remark>Changed the status to Retracted at the request of the author, since the proposed protocol was incompatible with XMPP and clients have begun using jabber:iq:private for this kind of functionality. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
30 30
     </revision>
31 31
     <revision>
32 32
       <version>0.1</version>
@@ -37,7 +37,7 @@
37 37
   </header>
38 38
 
39 39
   <section1 topic="Introduction">
40
-    <p>The main purpose of this JEP is to make roster not only a "contact list", but also a "list of useful items".  This means that the user has the ability to store not only users' JIDs, but any JID that he wants to quickly access with more information than just the name, subscription and roster groups.</p>
40
+    <p>The main purpose of this document is to make roster not only a "contact list", but also a "list of useful items".  This means that the user has the ability to store not only users' JIDs, but any JID that he wants to quickly access with more information than just the name, subscription and roster groups.</p>
41 41
   </section1>
42 42
 
43 43
   <section1 topic="What we need to store">

+ 2
- 2
xep-0066.xml View File

@@ -50,7 +50,7 @@
50 50
     <version>1.2</version>
51 51
     <date>2004-04-13</date>
52 52
     <initials>psa</initials>
53
-    <remark><p>Clarified that IQ use is for basic file transfer whereas message and presence use is for communication of URIs; added presence example; added references to file transfer JEPs as well as related open issue.</p></remark>
53
+    <remark><p>Clarified that IQ use is for basic file transfer whereas message and presence use is for communication of URIs; added presence example; added references to file transfer specifications as well as related open issue.</p></remark>
54 54
   </revision>
55 55
   <revision>
56 56
     <version>1.1</version>
@@ -227,7 +227,7 @@
227 227
 <section1 topic='IANA Considerations' anchor='iana'>
228 228
   <p>This document requires no interaction with &IANA;.</p>
229 229
 </section1>
230
-<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
230
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
231 231
   <p>The 'jabber:iq:oob' and 'jabber:x:oob' namespaces are included in the protocol namespaces registry maintained by the &REGISTRAR; (see &NAMESPACES;).</p>
232 232
 </section1>
233 233
 <section1 topic='XML Schemas' anchor='schemas'>

+ 2
- 2
xep-0067.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
 <title>Stock Data Transmission</title>
10
-<abstract>This JEP specifies a data format for stock data distribution in the Jabber community.</abstract>
10
+<abstract>This document specifies a data format for stock data distribution in the Jabber community.</abstract>
11 11
 &LEGALNOTICE;
12 12
 <number>0067</number>
13 13
 <status>Deferred</status>
@@ -47,7 +47,7 @@
47 47
 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. 
48 48
 </p>
49 49
 <p>
50
-So, what this JEP 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.
50
+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.
51 51
 </p>
52 52
 <p>In a non pubsub environment stock data SHALL be transmitted in the x-chunk, identified with the namespace 'http://www.jabber.org/jeps/jep-0067.html', embedded into a message chunk.
53 53
 </p></section1>

+ 1
- 1
xep-0068.xml View File

@@ -341,7 +341,7 @@
341 341
         <code><![CDATA[
342 342
 <form_type>
343 343
   <name>FORM_TYPE namespace or namespace derivative</name>
344
-  <doc>associated JEP or other document</doc>
344
+  <doc>associated specification</doc>
345 345
   <desc>natural-language description of form type</desc>
346 346
   <field
347 347
       var='the_field_name'

+ 2
- 2
xep-0071.xml View File

@@ -820,13 +820,13 @@ That seems fine to me.
820 820
     <p>The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C; before this specification proceeds to a status of Final within the Jabber Software Foundation's standards process, it should undergo a formal review through communication with the Hypertext Coordination Group within the W3C.</p>
821 821
   </section2>
822 822
   <section2 topic='XHTML Versioning' anchor='w3c-versions'>
823
-    <p>The W3C is actively working on &w3xhtml2; and may produce additional versions of XHTML in the future. This specification addresses XHTML 1.0 only, but it may be superseded or supplemented in the future by a Jabber Enhancement Proposal that defines methods for encapsulating XHTML 2.0 content in XMPP.</p>
823
+    <p>The W3C is actively working on &w3xhtml2; and may produce additional versions of XHTML in the future. This specification addresses XHTML 1.0 only, but it may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating XHTML 2.0 content in XMPP.</p>
824 824
   </section2>
825 825
 </section1>
826 826
 <section1 topic='IANA Considerations' anchor='iana'>
827 827
   <p>This document requires no interaction with &IANA;.</p>
828 828
 </section1>
829
-<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
829
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
830 830
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
831 831
     <p>The &REGISTRAR; includes 'http://jabber.org/protocol/xhtml-im' in its registry of protocol namespaces.</p>
832 832
   </section2>

+ 3
- 3
xep-0072.xml View File

@@ -1039,7 +1039,7 @@
1039 1039
     <p>As was done with &xep0071;, the SOAP XMPP Binding defined herein has been reviewed informally by one or more appropriate experts from the W3C before the &COUNCIL; advanced it to a status of Draft within the JSF's standards process. Before this specification proceeds to a status of Final within the JSF's standards process, it should undergo a formal review through communication with the W3C's <link url='http://www.w3.org/2000/xp/Group/'>XML Protocol Working Group</link>. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.</p>
1040 1040
   </section2>
1041 1041
   <section2 topic='SOAP Versioning' anchor='w3c-soapversions'>
1042
-    <p>This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a Jabber Enhancement Proposal that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.</p>
1042
+    <p>This specification addresses SOAP 1.2 only. This specification may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating content defined by future versions of SOAP as published by the W3C.</p>
1043 1043
   </section2>
1044 1044
   <section2 topic='XML Versioning' anchor='w3c-xmlversions'>
1045 1045
     <p>Per <cite>RFC 3920</cite>, XMPP supports XML 1.0 only. If future versions of XMPP support XML 1.1 or subsequent versions, this specification may be modified to address handling of SOAP messages that are encoded in versions other than XML 1.0.</p>
@@ -1100,12 +1100,12 @@
1100 1100
   <p>No interaction with &IANA; is required by this document.</p>
1101 1101
 </section1>
1102 1102
 
1103
-<section1 topic="Jabber Registrar Considerations" anchor='registrar'>
1103
+<section1 topic="XMPP Registrar Considerations" anchor='registrar'>
1104 1104
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
1105 1105
     <p>The &REGISTRAR; includes 'http://jabber.org/protocol/soap' and 'http://jabber.org/protocol/soap#fault' in its registry of protocol namespaces.</p>
1106 1106
   </section2>
1107 1107
   <section2 topic='Service Discovery Identity' anchor='registrar-disco'>
1108
-    <p>The Jabber Registrar includes a Service Discovery type of "soap" within the "automation" category.</p>
1108
+    <p>The XMPP Registrar includes a Service Discovery type of "soap" within the "automation" category.</p>
1109 1109
     <p>The registry submission is as follows:</p>
1110 1110
     <code><![CDATA[
1111 1111
 <category>

+ 1
- 1
xep-0075.xml View File

@@ -1330,7 +1330,7 @@
1330 1330
     </section2>
1331 1331
   </section1>
1332 1332
   <section1 topic='IANA Considerations'>
1333
-    <p>This JEP requires no interaction with the IANA.</p>
1333
+    <p>This document requires no interaction with the IANA.</p>
1334 1334
   </section1>
1335 1335
   <section1 topic='XMPP Registrar Considerations'>
1336 1336
     <p>This protocol defines one new namespace, 'jabber:iq:joap'.</p>

+ 4
- 4
xep-0077.xml View File

@@ -139,7 +139,7 @@
139 139
   </revision>
140 140
 </header>
141 141
 <section1 topic='Introduction' anchor='intro'>
142
-  <p>The Jabber protocols have long included a method for in-band registration with instant messaging servers and associated services. This method makes use of the 'jabber:iq:register' namespace and has been documented variously in Internet-Drafts and elsewhere. Because in-band registration is not required by &rfc2779;, documentation of the 'jabber:iq:register' namespace was removed from &xmppim;. This JEP fills the void for canonical documentation.</p>
142
+  <p>The Jabber protocols have long included a method for in-band registration with instant messaging servers and associated services. This method makes use of the 'jabber:iq:register' namespace and has been documented variously in Internet-Drafts and elsewhere. Because in-band registration is not required by &rfc2779;, documentation of the 'jabber:iq:register' namespace was removed from &xmppim;. This specification fills the void for canonical documentation.</p>
143 143
 </section1>
144 144
 <section1 topic='Requirements' anchor='reqs'>
145 145
   <p>In-band registration must make it possible for an entity to register with a host, cancel an existing registration with a host, or change a password with a host. By "host" is meant either of the following:</p>
@@ -502,7 +502,7 @@
502 502
     <li>The x:data form SHOULD use a hidden FORM_TYPE field for the purpose of standardizing field names within the form, as defined in &xep0068;.</li>
503 503
     <li>The x:data form shall take precedence over the iq:register fields; if the submitting entity supports the <cite>Data Forms</cite> protocol, it SHOULD submit the data form rather than the predefined 'jabber:iq:register' fields, and MUST NOT submit both the data form and the predefined fields (see the <link url='#precedence'>Precedence Order</link> section of this document).</li>
504 504
   </ol>
505
-  <p>Support for extensibility via <cite>Data Forms</cite> is RECOMMENDED but is not required for compliance with this JEP.</p>
505
+  <p>Support for extensibility via <cite>Data Forms</cite> is RECOMMENDED but is not required for compliance with this document.</p>
506 506
 </section1>
507 507
 <section1 topic='Redirection' anchor='redirect'>
508 508
   <p>A given deployment MAY wish to redirect users to another medium (e.g., a website) for registration, rather than allowing in-band registration. The recommended approach is to include only the &lt;instructions/&gt; element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066; (see the <link url="#precedence">Precedence Order</link> section below for further details).</p>
@@ -605,10 +605,10 @@
605 605
   <p>As defined herein, the 'jabber:iq:register' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in XMPP Core. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both. For mappings of HTTP-style errors to XMPP-style conditions, refer to &xep0086;.</p>
606 606
 </section1>
607 607
 <section1 topic='Security Considerations' anchor='security'>
608
-  <p>In-band registration is usually not included in other messaging protocols (for example, SMTP does not include a method for registering with an email server), often for reasons of security. The registration methods defined herein are known to be insecure and SHOULD NOT be used unless the channel between the registrant and the entity that accepts registration has been secured. For these reasons, the deployment of in-band registration is a policy matter and a given deployment MAY choose to disable in-band registration and password changes. Furthermore, this JEP should be deprecated as soon as a successor protocol is defined and implemented.</p>
608
+  <p>In-band registration is usually not included in other messaging protocols (for example, SMTP does not include a method for registering with an email server), often for reasons of security. The registration methods defined herein are known to be insecure and SHOULD NOT be used unless the channel between the registrant and the entity that accepts registration has been secured. For these reasons, the deployment of in-band registration is a policy matter and a given deployment MAY choose to disable in-band registration and password changes. Furthermore, this document should be deprecated as soon as a successor protocol is defined and implemented.</p>
609 609
 </section1>
610 610
 <section1 topic='IANA Considerations' anchor='iana'>
611
-  <p>This JEP requires no interaction with &IANA;.</p>
611
+  <p>This document requires no interaction with &IANA;.</p>
612 612
 </section1>
613 613
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
614 614
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

+ 1
- 1
xep-0078.xml View File

@@ -285,7 +285,7 @@
285 285
   <p>As defined herein, the 'jabber:iq:auth' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in <cite>RFC 3920</cite>. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.</p>
286 286
 </section1>
287 287
 <section1 topic='Expiration Date' anchor='expiration'>
288
-  <p>In accordance with Section 8 of &xep0001;, on 2004-10-20 this document was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council changed the status of this document to Deprecated. The Jabber Council will review this document every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the document is obsoleted. For the latest expiration date, refer to the XEP Information block at the beginning of this document.</p>
288
+  <p>In accordance with Section 8 of &xep0001;, on 2004-10-20 this document was advanced to a status of Final with the understanding that it would expire in six months. On 2006-09-13, the Jabber Council (now XMPP Council) changed the status of this document to Deprecated. The Jabber Council will review this document every six months to determine whether to change its status to Obsolete or to extend the expiration date for an additional six months; this process will continue until the document is obsoleted. For the latest expiration date, refer to the XEP Information block at the beginning of this document.</p>
289 289
 </section1>
290 290
 <section1 topic='Security Considerations' anchor='security'>
291 291
   <p>Use of the 'jabber:iq:auth' method for client-server authentication is not as secure as SASL authentication (defined in <cite>RFC 3920</cite>). If both client and server implement SASL, they MUST use SASL. If a client attempts to authenticate using the 'jabber:iq:auth' namespace after an attempt at SASL authentication fails, the server MUST refuse the 'jabber:iq:auth' attempt by returning a &lt;policy-violation/&gt; stream error to the client.</p>

+ 2
- 2
xep-0079.xml View File

@@ -78,13 +78,13 @@
78 78
     <version>0.9</version>
79 79
     <date>2004-04-25</date>
80 80
     <initials>psa</initials>
81
-    <remark>JEP Editor's review: clarified some matters in the text; fully defined the XMPP Registrar Considerations.</remark>
81
+    <remark>Editorial review: clarified some matters in the text; fully defined the XMPP Registrar Considerations.</remark>
82 82
   </revision>
83 83
   <revision>
84 84
     <version>0.8</version>
85 85
     <date>2004-01-20</date>
86 86
     <initials>lw</initials>
87
-    <remark>Reorganized for JEP Editor's preferences; revised error conditions to properly align with XMPP-Core</remark>
87
+    <remark>Reorganized for Editorial preferences; revised error conditions to properly align with XMPP-Core</remark>
88 88
   </revision>
89 89
   <revision>
90 90
     <version>0.7</version>

+ 1
- 1
xep-0080.xml View File

@@ -95,7 +95,7 @@
95 95
     <version>0.2</version>
96 96
     <date>2003-07-29</date>
97 97
     <initials>psa</initials>
98
-    <remark><p>Incorporated Standards JIG feedback; changed JEP type to Informational.</p></remark>
98
+    <remark><p>Incorporated Standards JIG feedback; changed document type to Informational.</p></remark>
99 99
   </revision>
100 100
   <revision>
101 101
     <version>0.1</version>

+ 2
- 2
xep-0095.xml View File

@@ -308,13 +308,13 @@
308 308
   </section2>
309 309
   <section2 topic='Registries' anchor='registrar-reg'>
310 310
     <section3 topic='Profiles Registry' anchor='registrar-reg-profiles'>
311
-      <p>The XMPP Registrar shall maintain a registry of stream initiation profiles, located at &lt;<link url='http://www.jabber.org/registrar/si-profiles.html'>http://www.jabber.org/registrar/si-profiles.html</link>&gt;. Any such profile defined in a Jabber Enhancement Proposal MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.</p>
311
+      <p>The XMPP Registrar shall maintain a registry of stream initiation profiles, located at &lt;<link url='http://www.jabber.org/registrar/si-profiles.html'>http://www.jabber.org/registrar/si-profiles.html</link>&gt;. Any such profile defined in a XMPP Extension Protocol specification MUST be submitted to the XMPP Registrar; profiles defined in non-standard protocol extensions SHOULD be submitted to the XMPP Registrar.</p>
312 312
       <section4 topic='Process' anchor='registrar-reg-profiles-process'>
313 313
         &REGPROCESS;
314 314
         <code><![CDATA[
315 315
 <profile>
316 316
   <name>The profile name</name>
317
-  <doc>The JEP or other document that defines the profile</doc>
317
+  <doc>The specification that defines the profile</doc>
318 318
   <desc>A natural-language description of the profile</desc>
319 319
 </profile>
320 320
         ]]></code>

+ 5
- 5
xep-0097.xml View File

@@ -31,8 +31,8 @@
31 31
     </revision>
32 32
   </header>
33 33
   <section1 topic='Introduction'>
34
-    <p>This will be the first, in a series (hopefully), of JEPs which will define how to utilize GroupWare over jabber. While GroupWare is extremely broad subject, this JEP will focus on iCal<note>iCalendar <link uri='http://www.ietf.org/html.charters/calsch-charter.html'>http://www.ietf.org/html.charters/calsch-charter.html</link></note>. Since iCal is a defined standard which is transport-agnostic, all this JEP will do is define how iCal will be transported over Jabber.</p>
35
-    <p>What this JEP will cover:</p>
34
+    <p>This will be the first, in a series (hopefully), of specifications which will define how to utilize GroupWare over jabber. While GroupWare is extremely broad subject, this document will focus on iCal<note>iCalendar <link uri='http://www.ietf.org/html.charters/calsch-charter.html'>http://www.ietf.org/html.charters/calsch-charter.html</link></note>. Since iCal is a defined standard which is transport-agnostic, all this document will do is define how iCal will be transported over Jabber.</p>
35
+    <p>What this document will cover:</p>
36 36
     <ul>
37 37
       <li>Sending iCal data</li>
38 38
       <li>Receiving iCal data</li>
@@ -87,7 +87,7 @@
87 87
       DTSTART:20030422T220000Z
88 88
       DTEND:20030422T230000Z
89 89
       SEQUENCE:3
90
-      SUMMARY:JEPs
90
+      SUMMARY:XEPs
91 91
       LOCATION:foundation@conference.jabber.org
92 92
       CATEGORIES:JSF
93 93
       CLASS:PUBLIC
@@ -115,10 +115,10 @@
115 115
     <p>Most users today have some form of calendaring functionality available to them which supports the iCal standard. Simply redirecting the received ical to the user's preferred calendaring application would be the ideal scenario.</p>
116 116
   </section1>
117 117
   <section1 topic='IANA Considerations'>
118
-    <p>This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA)</p>
118
+    <p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA)</p>
119 119
   </section1>
120 120
   <section1 topic='XMPP Registrar Considerations'>
121
-    <p>The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this JEP.</p>
121
+    <p>The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this document.</p>
122 122
   </section1>
123 123
   <section1 topic='Formal Definition'>
124 124
     <section2 topic='Schema'>

+ 2
- 2
xep-0099.xml View File

@@ -33,7 +33,7 @@
33 33
 <section1 topic='Introduction'>
34 34
   <p>There is a need for consistent query behavior amongst XMPP &IQ; protocols. Currently
35 35
 each protocol invents it's own, slightly different behavior for conducting 
36
-query behavior to create, read, update, and delete (CRUD) recipient node data. This JEP defines a generic
36
+query behavior to create, read, update, and delete (CRUD) recipient node data. This document defines a generic
37 37
 query acton protocol to standardize behavior across &IQ; protocols. In addition, we hope
38 38
 this standard will make other protocols easier to understand and implement by using a common
39 39
 core protocol.</p>
@@ -381,7 +381,7 @@ RECIPIENT:
381 381
 <section1 topic='Defining an Action Protocol'>
382 382
   <section2 topic='Description'>
383 383
     <p>In order to define an action protocol that uses the &QUERY; behavior defined in
384
-this JEP, you must specify the following:</p>
384
+this document, you must specify the following:</p>
385 385
     <ul>
386 386
       <li>The actions (create, read, update, delete) supported in the action protocol.</li>
387 387
       <li>The matching semantics for determing if data exists/collides.</li>

+ 1
- 1
xep-0103.xml View File

@@ -26,7 +26,7 @@
26 26
     <version>0.4</version>
27 27
     <date>2004-01-20</date>
28 28
     <initials>lw</initials>
29
-    <remark>Reorganized for JEP Editor preferences; revised error conditions; added better localization for &lt;desc/&gt;</remark>
29
+    <remark>Reorganized for Editorial preferences; revised error conditions; added better localization for &lt;desc/&gt;</remark>
30 30
   </revision>
31 31
   <revision>
32 32
     <version>0.4</version>

+ 1
- 1
xep-0104.xml View File

@@ -33,7 +33,7 @@
33 33
     <version>0.3</version>
34 34
     <date>2004-01-20</date>
35 35
     <initials>lw</initials>
36
-    <remark>Reorganized for JEP Editor preferences; Removed (outdated) references to XEP-0070</remark>
36
+    <remark>Reorganized for Editorial preferences; Removed (outdated) references to XEP-0070</remark>
37 37
   </revision>
38 38
   <revision>
39 39
     <version>0.2</version>

+ 6
- 6
xep-0107.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
   <title>User Mood</title>
10
-  <abstract>This JEP defines a protocol for communicating information about user moods.</abstract>
10
+  <abstract>This document defines an XMPP protocol extension for communicating information about user moods.</abstract>
11 11
   &LEGALNOTICE;
12 12
   <number>0107</number>
13 13
   <status>Draft</status>
@@ -69,7 +69,7 @@
69 69
   </revision>
70 70
 </header>
71 71
 <section1 topic='Introduction' anchor='intro'>
72
-  <p>This JEP defines an extension mechanism for capturing "extended presence" data about user moods.</p>
72
+  <p>This document defines an extension mechanism for capturing "extended presence" data about user moods.</p>
73 73
 </section1>
74 74
 <section1 topic='Protocol' anchor='proto'>
75 75
   <section2 topic='Data Format' anchor='proto-format'>
@@ -77,7 +77,7 @@
77 77
     <code><![CDATA[
78 78
 <mood xmlns='http://jabber.org/protocol/mood'>
79 79
   <happy/>
80
-  <text>Yay, the mood JEP has been approved!</text>
80
+  <text>Yay, the mood document has been approved!</text>
81 81
 </mood>
82 82
     ]]></code>
83 83
     <p>In addition, an application MAY provide a more specific mood value as a properly-namespaced child of the defined element, which extension MUST be ignored if the receiving application does not understand the extended namespace. Here is an example:</p>
@@ -86,7 +86,7 @@
86 86
   <happy>
87 87
     <ecstatic xmlns='http://ik.nu/ralphm'/>
88 88
   </happy>
89
-  <text>Yay, the mood JEP has been approved!</text>
89
+  <text>Yay, the mood document has been approved!</text>
90 90
 </mood>
91 91
     ]]></code>
92 92
   </section2>
@@ -171,7 +171,7 @@
171 171
   <body>Cool!</body>
172 172
   <mood xmlns='http://jabber.org/protocol/mood'>
173 173
     <happy/>
174
-    <text>Yay, the mood JEP has been published!</text>
174
+    <text>Yay, the mood document has been published!</text>
175 175
     <x xmlns='jabber:x:oob'>
176 176
       <url>http://www.xmpp.org/extensions/xep-0107.html</url>
177 177
     </x>
@@ -271,7 +271,7 @@
271 271
   <p>Because user moods may be published to a large number of pubsub subscribers, users should take care in approving subscribers and in characterizing their current moods.</p>
272 272
 </section1>
273 273
 <section1 topic='IANA Considerations' anchor='iana'>
274
-  <p>This JEP requires no interaction with &IANA;.</p>
274
+  <p>This document requires no interaction with &IANA;.</p>
275 275
 </section1>
276 276
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
277 277
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

+ 1
- 1
xep-0109.xml View File

@@ -27,7 +27,7 @@
27 27
     <version>0.2</version>
28 28
     <date>2003-08-12</date>
29 29
     <initials>rn</initials>
30
-    <remark>Added use cases for removing vacation settings; described semantics when start and end times are not specified; changed JEP type to Informational; small editorial changes.</remark>
30
+    <remark>Added use cases for removing vacation settings; described semantics when start and end times are not specified; changed document type to Informational; small editorial changes.</remark>
31 31
   </revision>
32 32
   <revision>
33 33
     <version>0.1</version>

+ 1
- 1
xep-0111.xml View File

@@ -65,7 +65,7 @@
65 65
     <version>0.2</version>
66 66
     <date>2003-07-29</date>
67 67
     <initials>psa</initials>
68
-    <remark>Converted to JEP format.</remark>
68
+    <remark>Converted to XML format.</remark>
69 69
   </revision>
70 70
   <revision>
71 71
     <version>0.1</version>

+ 1
- 1
xep-0116.xml View File

@@ -127,7 +127,7 @@
127 127
     <version>0.2</version>
128 128
     <date>2004-07-26</date>
129 129
     <initials>psa</initials>
130
-    <remark><p>At the request of the JEP author, changed status to Retracted.</p></remark>
130
+    <remark><p>At the request of the author, changed status to Retracted.</p></remark>
131 131
   </revision>
132 132
   <revision>
133 133
     <version>0.1</version>

+ 1
- 1
xep-0118.xml View File

@@ -71,7 +71,7 @@
71 71
     <version>0.4</version>
72 72
     <date>2003-12-14</date>
73 73
     <initials>psa</initials>
74
-    <remark>Slight modifications to track changes to infobits JEPs.</remark>
74
+    <remark>Slight modifications to track changes to infobits specifications.</remark>
75 75
   </revision>
76 76
   <revision>
77 77
     <version>0.3</version>

+ 6
- 6
xep-0120.xml View File

@@ -67,7 +67,7 @@
67 67
   <section2 topic='Protocol Basics'>
68 68
     <p>The "infobits" protocol defined herein provides a data format only. The container element is &lt;info/&gt;, which is qualified by the 'http://jabber.org/protocol/infobits' namespace. There is one allowable child of the &lt;info/&gt; element -- &lt;bundle/&gt; -- and one allowable child of the &lt;bundle/&gt; element -- &lt;bit/&gt;. In order to provide the relevant metadata, the &lt;info/&gt; element MAY contain an unbounded number of &lt;bundle/&gt; elements, each of which MAY contain an unbounded number of &lt;bit/&gt; elements.</p>
69 69
     <p>Each &lt;bundle/&gt; element MUST possess a 'type' attribute, whose value specifies the aspect of reality to which the enclosed bits apply (e.g., geographical location). A &lt;bundle/&gt; element MAY also possess a 'context' attribute, whose value provides further specifying information about the kind of entities described by this bundle (e.g., a home address as opposed to a work address).</p>
70
-    <p>Each &lt;bit/&gt; element MUST possess a 'key' attribute, whose value specifies the name of the key (this MUST be an NMTOKEN as defined in &w3xml;). A &lt;bit/&gt; element MAY also possess a 'datatype' attribute, whose value specifies the datatype of the key (which SHOULD be a datatype specified in &w3xmlschema2; or in a registry of values maintained by the Jabber Registrar, such as those described in &xep0122;). The &lt;bit/&gt; element SHOULD contain XML character data that specifies the relevant value of the 'key'. A &lt;bundle/&gt; element MAY contain more than one &lt;bit/&gt; element with the same value for the 'key' attribute when necessary (e.g., two instances of 'weblog' if the person has multiple weblogs), but obviously SHOULD NOT do so if a collision would occur (e.g., two instances of 'lat' and 'lon' to define a geographical location).</p>
70
+    <p>Each &lt;bit/&gt; element MUST possess a 'key' attribute, whose value specifies the name of the key (this MUST be an NMTOKEN as defined in &w3xml;). A &lt;bit/&gt; element MAY also possess a 'datatype' attribute, whose value specifies the datatype of the key (which SHOULD be a datatype specified in &w3xmlschema2; or in a registry of values maintained by the XMPP Registrar, such as those described in &xep0122;). The &lt;bit/&gt; element SHOULD contain XML character data that specifies the relevant value of the 'key'. A &lt;bundle/&gt; element MAY contain more than one &lt;bit/&gt; element with the same value for the 'key' attribute when necessary (e.g., two instances of 'weblog' if the person has multiple weblogs), but obviously SHOULD NOT do so if a collision would occur (e.g., two instances of 'lat' and 'lon' to define a geographical location).</p>
71 71
     <p><em><strong>Note well:</strong> no keys are defined in this document. All such keys MUST be defined in separate specifications. Keys and associated values shown in this document are provided for explanatory purposes only.</em></p>
72 72
   </section2>
73 73
   <section2 topic='Discovering Support'>
@@ -223,20 +223,20 @@
223 223
   <p>Data provided via the infobits protocol MAY be world-readable. Access control considerations MUST be defined by any protocol that makes use of infobits.</p>
224 224
 </section1>
225 225
 <section1 topic='Internationalization Considerations'>
226
-  <p>Info key names registered with the Jabber Registrar MUST be considered as identifiers, not English-language words. For purposes of internationalization, an identifier SHOULD be rendered as a word or phrase that is appropriate to the end user's preferred language.</p>
226
+  <p>Info key names registered with the XMPP Registrar MUST be considered as identifiers, not English-language words. For purposes of internationalization, an identifier SHOULD be rendered as a word or phrase that is appropriate to the end user's preferred language.</p>
227 227
 </section1>
228 228
 <section1 topic='IANA Considerations'>
229 229
   <p>This document requires no interaction with &IANA;.</p>
230 230
 </section1>
231
-<section1 topic='Jabber Registrar Considerations'>
231
+<section1 topic='XMPP Registrar Considerations'>
232 232
   <section2 topic='Namespaces'>
233 233
     <p>Upon advancement of this proposal to a status of Draft, the &REGISTRAR; shall add the 'http://jabber.org/protocol/infobits' namespace to its registry of official namespaces.</p>
234 234
   </section2>
235 235
   <section2 topic='Registries'>
236
-    <p>The Jabber Registrar shall maintain a registry of infobit keynames and associated information.</p>
236
+    <p>The XMPP Registrar shall maintain a registry of infobit keynames and associated information.</p>
237 237
     <p>All keynames MUST begin with a short prefix string (letters and numbers only), followed by the '.' character used as a separator, followed by the name of the key as determined by the particular specification or organization that is identified with the prefix. Arbitrary keynames SHOULD begin with a prefix consisting of the capital 'X' character.</p>
238
-    <p>The Jabber Registrar shall at its discretion reserve certain keyname prefixes for use in specifying particular classes of information. One example is the prefix 'DC', which is reserved for use by infobits specified by the &DUBLINCORE; (for details, see &xep0121;). Furthermore, the Jabber Registrar shall reserve the "XMPP" prefix for infobits related to documents created by the &XMPPWG; or its successors, and shall reserve the upper-case versions of all protocol "shortnames" specified in Jabber Enhancement Proposals (e.g., a prefix of "MUC" for infobits related to &xep0045;).</p>
239
-    <p>In order to prevent naming collisions, infobits that will be used in public protocols that may interoperate with other protocols on the network SHOULD be registered with the Jabber Registrar, and MUST be so registered if they are defined in Jabber Enhancement Proposals (however, registration of private keys is NOT REQUIRED). Registration with the Jabber Registrar shall be considered to entail reservation of that infobit on the network, and a registered bit MUST NOT be re-used by other protocols and applications for purposes other than those implied by the registry entry.</p>
238
+    <p>The XMPP Registrar shall at its discretion reserve certain keyname prefixes for use in specifying particular classes of information. One example is the prefix 'DC', which is reserved for use by infobits specified by the &DUBLINCORE; (for details, see &xep0121;). Furthermore, the XMPP Registrar shall reserve the "XMPP" prefix for infobits related to documents created by the &XMPPWG; or its successors, and shall reserve the upper-case versions of all protocol "shortnames" specified in XMPP Extension Protocol specifications (e.g., a prefix of "MUC" for infobits related to &xep0045;).</p>
239
+    <p>In order to prevent naming collisions, infobits that will be used in public protocols that may interoperate with other protocols on the network SHOULD be registered with the XMPP Registrar, and MUST be so registered if they are defined in XMPP Extension Protocol specifications (however, registration of private keys is NOT REQUIRED). Registration with the XMPP Registrar shall be considered to entail reservation of that infobit on the network, and a registered bit MUST NOT be re-used by other protocols and applications for purposes other than those implied by the registry entry.</p>
240 240
     <p>In addition to the key name, the following data may be provided (but is not required) for each bit:</p>
241 241
     <ol>
242 242
       <li>datatype -- provide only if well-defined; otherwise assume string</li>

+ 1
- 1
xep-0121.xml View File

@@ -59,7 +59,7 @@
59 59
   </revision>
60 60
 </header>
61 61
 <section1 topic='Introduction'>
62
-  <p>&xep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This document specifies how to encapsulate one sort of metadata in infobits: the common metadata elements defined by the &DUBLINCORE;. Note well that this document is decidedly <em>not</em> meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the &REGISTRAR;, will specify additional infobits.</p>
62
+  <p>&xep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This document specifies how to encapsulate one sort of metadata in infobits: the common metadata elements defined by the &DUBLINCORE;. Note well that this document is decidedly <em>not</em> meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in XMPP Extension Protocol specifications or direct submissions to the &REGISTRAR;, will specify additional infobits.</p>
63 63
 </section1>
64 64
 <section1 topic='Dublin Core Metadata Terms'>
65 65
   <p>The Dublin Core Metadata Initiative defines a number of common elements and element refinements that can be used to specify metadata about entities (especially but not exclusively publications). The semantics of any Dublin Core term can be represented as a Jabber infobit, where the infobit keyname consists of the term name (not label) prepended by a 'DC' prefix and a '.' separator character. Thus "DC.creator" is a valid infobit name and can be used to describe, for example, an IM user's relationship to the URI identifying the user's homepage or weblog. Infobit keynames beginning with the 'DC' prefix are reserved for &dcmiterms; only (the canonical list of these terms is available from the Dublin Core Metadata Initiative and is included here only for explanatory purposes).</p>

+ 1
- 1
xep-0125.xml View File

@@ -29,7 +29,7 @@
29 29
   </revision>
30 30
 </header>
31 31
 <section1 topic='Introduction'>
32
-  <p>&xep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This document specifies how to encapsulate one sort of metadata in infobits: the metadata elements about entities defined by &rfc2426; (supplemented by vCard-like metadata that is not defined in RFC 2426), thus enabling the Jabber community to supersede &xep0054;. Note well that this document is decidedly <em>not</em> meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the &REGISTRAR;, will specify additional infobits.</p>
32
+  <p>&xep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This document specifies how to encapsulate one sort of metadata in infobits: the metadata elements about entities defined by &rfc2426; (supplemented by vCard-like metadata that is not defined in RFC 2426), thus enabling the Jabber community to supersede &xep0054;. Note well that this document is decidedly <em>not</em> meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in XMPP Extension Protocol specifications or direct submissions to the &REGISTRAR;, will specify additional infobits.</p>
33 33
 </section1>
34 34
 <section1 topic='vCard Mapping'>
35 35
   <p>In order to supersede the vCard-XML protocol currently in use within the Jabber community, it is necessary to define infobits that correspond to the data elements defined by the vCard-XML DTD (more precisely, the vCard Profile Features specified in section 3 of RFC 2426). These are shown in the following table. (Note: this mapping uses the vCard entity names specified in &dawson3;, not those specified in XEP-0054.)</p>

+ 1
- 1
xep-0128.xml View File

@@ -63,7 +63,7 @@
63 63
   </query>
64 64
 </iq>]]></code>
65 65
   <p>Note: A &lt;field/&gt; element MAY contain more than one &lt;value/&gt; child if appropriate.</p>
66
-  <p>If the data fields are to be used in the context of a protocol approved by the Jabber Software Foundation, they SHOULD be described in the relevant Jabber Enhancement Proposal and registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a &lt;field/&gt; element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".</p>
66
+  <p>If the data fields are to be used in the context of a protocol approved by the Jabber Software Foundation, they SHOULD be described in the relevant XMPP Extension Protocol specification and registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a &lt;field/&gt; element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".</p>
67 67
   <p>An entity MUST NOT supply extended information about associated children communicated via the 'http://jabber.org/protocol/disco#items' namespace, since a core principle of <cite>Service Discovery</cite> is that an entity must define its own identity only and must not define the identity of any children associated with the entity.</p>
68 68
 </section1>
69 69
 <section1 topic='Examples' anchor='examples'>

+ 1
- 1
xep-0129.xml View File

@@ -214,7 +214,7 @@
214 214
 <section1 topic='IANA Considerations' anchor='iana'>
215 215
   <p>This document requires no interaction with &IANA;.</p>
216 216
 </section1>
217
-<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
217
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
218 218
   <p>Upon advancement of this document to a status of Active, the &REGISTRAR; shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.</p>
219 219
 </section1>
220 220
 </xep>

+ 1
- 1
xep-0131.xml View File

@@ -178,7 +178,7 @@
178 178
 </section1>
179 179
 <section1 topic='Header Definitions' anchor='headers'>
180 180
   <p>All public headers SHOULD be registered with the XMPP Registrar following the process specified in the <link url="#registrar">XMPP Registrar Considerations</link> section of this document. Many such headers are defined by other protocol specifications, such as RFCs 2045, 2616, 2617, 2822, and 3261; implementors MUST refer to those specifications for definition of the relevant headers.</p>
181
-  <p>This document defines several additional headers that may prove useful within Jabber protocols and other XMPP extensions, as specified in the following sections; further headers may be registered with the XMPP Registrar, either directly or via definition in Jabber Enhancement Proposals.</p>
181
+  <p>This document defines several additional headers that may prove useful within Jabber protocols and other XMPP extensions, as specified in the following sections; further headers may be registered with the XMPP Registrar, either directly or via definition in XMPP Extension Protocol specifications.</p>
182 182
   <section2 topic='Classification' anchor='headers-classification'>
183 183
     <p>The Classification header enables a sender or other entity to classify a stanza according to some classification scheme. The values of the XML character data contained within this header are out of scope for this document, since they are determined by the using application. Note: This header may be security-sensitive (see the <link url='#security'>Security Considerations</link> for details).</p>
184 184
   </section2>

+ 1
- 1
xep-0134.xml View File

@@ -97,7 +97,7 @@
97 97
     <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>
98 98
     <p><em>Meaning</em></p>
99 99
     <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 
100
-      <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 Jabber Enhancement Proposals, the Jabber 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>
100
+      <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>
101 101
     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>
102 102
     <p><em>Examples</em></p>
103 103
     <p>&xep0096; is a good example of respecting the strengths and weaknesses of XMPP, since it specifies that going out of band is the preferred mechanism for bandwidth-heavy data transfers.</p>

+ 5
- 5
xep-0137.xml View File

@@ -52,7 +52,7 @@
52 52
   </revision>
53 53
 </header>
54 54
 <section1 topic='Introduction' anchor='intro'>
55
-  <p>&xep0095; defines a protocol to initiate a data stream between two Jabber/XMPP entities (e.g., for the purpose of &xep0096;). However, the sender is still responsible for informing potential receivers about the existence of a given stream. This JEP provides an automated way for a sender to announce the availability of a stream without initiating the data transfer. The purpose is to provide a "pull" protocol that enables a receiver to then request initiation of the stream from the sender.</p>
55
+  <p>&xep0095; defines a protocol to initiate a data stream between two Jabber/XMPP entities (e.g., for the purpose of &xep0096;). However, the sender is still responsible for informing potential receivers about the existence of a given stream. This document provides an automated way for a sender to announce the availability of a stream without initiating the data transfer. The purpose is to provide a "pull" protocol that enables a receiver to then request initiation of the stream from the sender.</p>
56 56
 </section1>
57 57
 <section1 topic='Requirements' anchor='requirements'>
58 58
   <p>This proposal addresses the following requirements:</p>
@@ -243,10 +243,10 @@
243 243
   </section2>
244 244
 </section1>
245 245
 <section1 topic='Security Considerations' anchor='security'>
246
-  <p>This JEP introduces no security concerns beyond those specified in <cite>XEP-0060</cite> and the relevant Stream Initiation profile in use.</p>
246
+  <p>This document introduces no security concerns beyond those specified in <cite>XEP-0060</cite> and the relevant Stream Initiation profile in use.</p>
247 247
 </section1>
248 248
 <section1 topic='IANA Considerations' anchor='iana'>
249
-  <p>This JEP requires no interaction with &IANA;.</p>
249
+  <p>This document requires no interaction with &IANA;.</p>
250 250
 </section1>
251 251
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
252 252
   <section2 topic='Protocol Namespaces' anchor='registrar.namespaces'>
@@ -254,7 +254,7 @@
254 254
   </section2>
255 255
   <section2 topic='Data Form Validation Datatypes' anchor='registrar.xdata-validate'>
256 256
     <p>The XMPP Registrar includes 'sipub:' in its registry of Data Forms Validation Datatype Prefixes.</p>
257
-    <p>Normally, each SI profile that wishes to be considered for use with Data Forms MUST register its own datatype qualified by the "sipub:" prefix. However, this JEP provides an initial seed, based on the currently accepted SI profiles. The following datatypes shall be registered for use with Data Forms Validation:</p>
257
+    <p>Normally, each SI profile that wishes to be considered for use with Data Forms MUST register its own datatype qualified by the "sipub:" prefix. However, this document provides an initial seed, based on the currently accepted SI profiles. The following datatypes shall be registered for use with Data Forms Validation:</p>
258 258
     <code caption='Data Forms Validation Datatypes Registry Submission'><![CDATA[
259 259
 <datatype>
260 260
   <name>sipub:file-transfer</name>
@@ -277,7 +277,7 @@
277 277
   <xs:annotation>
278 278
     <xs:documentation>
279 279
       The protocol documented by this schema is defined in
280
-      XEP-0137: http://www.jabber.org/xeps/xep-0137.html
280
+      XEP-0137: http://www.xmpp.org/extensions/xep-0137.html
281 281
     </xs:documentation>
282 282
   </xs:annotation>
283 283
 

+ 1
- 1
xep-0141.xml View File

@@ -40,7 +40,7 @@
40 40
     <version>0.2</version>
41 41
     <date>2005-03-28</date>
42 42
     <initials>psa</initials>
43
-    <remark>JEP Editor review: cleanup of text, examples, and schema.</remark>
43
+    <remark>Editorial review: cleanup of text, examples, and schema.</remark>
44 44
   </revision>
45 45
   <revision>
46 46
     <version>0.1</version>

+ 5
- 5
xep-0144.xml View File

@@ -7,7 +7,7 @@
7 7
 <xep>
8 8
 <header>
9 9
   <title>Roster Item Exchange</title>
10
-  <abstract>This JEP defines a protocol for exchanging roster items, including the ability to suggest whether the item is to be added, deleted, or modified.</abstract>
10
+  <abstract>This document defines an XMPP protocol extension for exchanging roster items, including the ability to suggest whether the item is to be added, deleted, or modified.</abstract>
11 11
   &LEGALNOTICE;
12 12
   <number>0144</number>
13 13
   <status>Draft</status>
@@ -66,7 +66,7 @@
66 66
     <version>0.1</version>
67 67
     <date>2004-09-29</date>
68 68
     <initials>psa</initials>
69
-    <remark>Initial JEP version.</remark>
69
+    <remark>Initial version.</remark>
70 70
   </revision>
71 71
   <revision>
72 72
     <version>0.0.2</version>
@@ -82,7 +82,7 @@
82 82
   </revision>
83 83
 </header>
84 84
 <section1 topic='Introduction' anchor='intro'>
85
-  <p>The Jabber protocols have long included a method for sending roster items from one entity to another, making use of the 'jabber:x:roster' namespace. Because this protocol extension was not required by &rfc2779;, it was removed from &xmppim; and documented for historical purposes in &xep0093;. However, since that time discussions in the &SJIG; have revealed that it would be helpful to use roster item exchange in the problem spaces of "shared groups" (e.g., predefined roster groups used within an organization) and roster synchronization (e.g., keeping a Jabber roster in sync with a contact list on a legacy IM service). These problem spaces require a slightly more sophisticated kind of roster item exchange than was documented in XEP-0093, specifically the ability to indicate whether a roster item is to be added, deleted, or modified. Therefore this JEP redefines roster item exchange to provide this functionality in a way that is backwards-compatible with existing implementations, albeit using a modern namespace URI of 'http://jabber.org/protocol/rosterx' rather than the old 'jabber:x:roster' namespace name. Further JEPs will specify how to solve the problems of shared groups and roster synchronization using the protocol defined herein.</p>
85
+  <p>The Jabber protocols have long included a method for sending roster items from one entity to another, making use of the 'jabber:x:roster' namespace. Because this protocol extension was not required by &rfc2779;, it was removed from &xmppim; and documented for historical purposes in &xep0093;. However, since that time discussions in the &SJIG; have revealed that it would be helpful to use roster item exchange in the problem spaces of "shared groups" (e.g., predefined roster groups used within an organization) and roster synchronization (e.g., keeping a Jabber roster in sync with a contact list on a legacy IM service). These problem spaces require a slightly more sophisticated kind of roster item exchange than was documented in XEP-0093, specifically the ability to indicate whether a roster item is to be added, deleted, or modified. Therefore this document redefines roster item exchange to provide this functionality in a way that is backwards-compatible with existing implementations, albeit using a modern namespace URI of 'http://jabber.org/protocol/rosterx' rather than the old 'jabber:x:roster' namespace name. Further specifications will define how to solve the problems of shared groups and roster synchronization using the protocol defined herein.</p>
86 86
 </section1>
87 87
 <section1 topic='Requirements' anchor='reqs'>
88 88
   <p>XEP-0093 did not define the requirements for roster item exchange. This section remedies that oversight.</p>
@@ -92,7 +92,7 @@
92 92
     <li>Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be deleted from the recipient's roster.</li>
93 93
     <li>Enable an entity to send one or more roster items to another entity, with the suggestion that the roster item(s) be modified in the recipient's roster.</li>
94 94
   </ol>
95
-  <p>This JEP deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in <cite>RFC 3921</cite>), they are not identical. The protocol defined herein enables an entity to suggest that another entity might want to add, delete, or modify roster items only, and does not dictate the suggested presence subscription state associated with those roster items. This is intentional.</p>
95
+  <p>This document deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in <cite>RFC 3921</cite>), they are not identical. The protocol defined herein enables an entity to suggest that another entity might want to add, delete, or modify roster items only, and does not dictate the suggested presence subscription state associated with those roster items. This is intentional.</p>
96 96
 </section1>
97 97
 <section1 topic='Use Cases' anchor='usecases'>
98 98
   <section2 topic='Suggesting Roster Item Addition' anchor='add'>
@@ -263,7 +263,7 @@
263 263
   </section2>
264 264
 </section1>
265 265
 <section1 topic='IANA Considerations' anchor='iana'>
266
-  <p>This JEP requires no interaction with &IANA;.</p>
266
+  <p>This document requires no interaction with &IANA;.</p>
267 267
 </section1>
268 268
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
269 269
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

+ 3
- 3
xep-0145.xml View File

@@ -40,7 +40,7 @@
40 40
       <version>0.2</version>
41 41
       <date>2005-07-15</date>
42 42
       <initials>psa</initials>
43
-      <remark><p>JEP Editor revisions: changed type to Historical; changed namespace to storage:rosternotes; corrected schema; specified use of DateTime profile from XEP-0082; corrected some small textual errors.</p></remark>
43
+      <remark><p>Editorial review: changed type to Historical; changed namespace to storage:rosternotes; corrected schema; specified use of DateTime profile from XEP-0082; corrected some small textual errors.</p></remark>
44 44
     </revision>
45 45
     <revision>
46 46
       <version>0.1</version>
@@ -117,11 +117,11 @@
117 117
   </section1>
118 118
 
119 119
   <section1 topic='IANA Considerations' anchor='iana'>
120
-    <p>No interaction with &IANA; is required as a result of this JEP.</p>
120
+    <p>No interaction with &IANA; is required as a result of this document.</p>
121 121
   </section1>
122 122
 
123 123
   <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
124
-    <p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p>
124
+    <p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
125 125
   </section1>
126 126
 
127 127
   <section1 topic='XML Schema' anchor='schema'>

+ 2
- 2
xep-0146.xml View File

@@ -658,10 +658,10 @@
658 658
 </section1>
659 659
 
660 660
 
661
-<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
661
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
662 662
     
663 663
     <section2 topic='Protocol Namespaces' anchor='registrar-protocol'>
664
-        <p>The Jabber Registrar includes 'http://jabber.org/protocol/rc' in its registry
664
+        <p>The XMPP Registrar includes 'http://jabber.org/protocol/rc' in its registry
665 665
         of protocol namespaces (see &NAMESPACES;).</p>
666 666
     </section2>
667 667
 

+ 1
- 1
xep-0148.xml View File

@@ -221,7 +221,7 @@
221 221
   <xs:annotation>
222 222
     <xs:documentation>
223 223
       The protocol documented by this schema is defined in
224
-      XEP-0148: http://www.jabber.org/xeps/xep-0148.html
224
+      XEP-0148: http://www.xmpp.org/extensions/xep-0148.html
225 225
     </xs:documentation>
226 226
   </xs:annotation>
227 227
 

+ 1
- 1
xep-0153.xml View File

@@ -48,7 +48,7 @@
48 48
     <version>0.1</version>
49 49
     <date>2005-06-16</date>
50 50
     <initials>psa</initials>
51
-    <remark>Initial JEP version.</remark>
51
+    <remark>Initial version.</remark>
52 52
   </revision>
53 53
   <revision>
54 54
     <version>0.0.3</version>

+ 1
- 1
xep-0154.xml View File

@@ -167,7 +167,7 @@
167 167
         </ol>
168 168
       </li>
169 169
     </ul>
170
-    <p>Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the &REGISTRAR; (although they may or may not be defined in a Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
170
+    <p>Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the &REGISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
171 171
     <p>The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:</p>
172 172
     <example caption='A Basic Example'><![CDATA[
173 173
 <profile xmlns='http://jabber.org/protocol/profile'>

+ 3
- 3
xep-0155.xml View File

@@ -41,7 +41,7 @@
41 41
     <version>0.6</version>
42 42
     <date>2006-07-13</date>
43 43
     <initials>psa</initials>
44
-    <remark><p>Specified that a client must re-initiate if it receives presence unavailable; changed JEP type to Standards Track.</p></remark>
44
+    <remark><p>Specified that a client must re-initiate if it receives presence unavailable; changed document type to Standards Track.</p></remark>
45 45
   </revision>
46 46
   <revision>
47 47
     <version>0.5</version>
@@ -71,7 +71,7 @@
71 71
     <version>0.1</version>
72 72
     <date>2005-07-14</date>
73 73
     <initials>psa</initials>
74
-    <remark><p>Initial JEP version.</p></remark>
74
+    <remark><p>Initial version.</p></remark>
75 75
   </revision>
76 76
   <revision>
77 77
     <version>0.0.1</version>
@@ -492,7 +492,7 @@ However, if the receiving party assumes that the other client will <em>not</em>
492 492
   <p>If a contact accepts a user's request or returns an error to the user, the user will effectively discover the contact's presence (at least the presence of one of the contact's resources). Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT <em>automatically</em> (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Furthermore, the contact's client MUST NOT take either action if the user is in the contact's block list.</p>
493 493
 </section1>
494 494
 <section1 topic='IANA Considerations' anchor='iana'>
495
-  <p>This JEP requires no interaction with &IANA;.</p>
495
+  <p>This document requires no interaction with &IANA;.</p>
496 496
 </section1>
497 497
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
498 498
   <section2 topic='Service Discovery Features' anchor='registrar-features'>

+ 2
- 2
xep-0156.xml View File

@@ -39,7 +39,7 @@
39 39
     <version>0.1</version>
40 40
     <date>2005-09-08</date>
41 41
     <initials>psa</initials>
42
-    <remark><p>Initial JEP version.</p></remark>
42
+    <remark><p>Initial version.</p></remark>
43 43
   </revision>
44 44
   <revision>
45 45
     <version>0.0.3</version>
@@ -106,7 +106,7 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector.cgi"
106 106
   <p>It is possible that advertisement of connection methods other than the standard TCP connection method may introduce security vulnerabilities, since a connecting entity (usually a client) might deliberately seek to connect using the method with the weakest security mechanisms (e.g., no channel encryption or relatively weak authentication). Care must be taken in determining which connection methods are appropriate to advertise.</p>
107 107
 </section1>
108 108
 <section1 topic='IANA Considerations' anchor='iana'>
109
-  <p>This JEP requires no interaction with &IANA;.</p>
109
+  <p>This document requires no interaction with &IANA;.</p>
110 110
 </section1>
111 111
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
112 112
   <section2 topic='DNS TXT Records Registry' anchor='registrar-dnstxt'>

+ 1
- 1
xep-0166.xml View File

@@ -821,6 +821,6 @@ PENDING  o---------------------+   |
821 821
   </section2>
822 822
 </section1>
823 823
 <section1 topic='Acknowledgements' anchor='ack'>
824
-  <p>The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ij&#228;s, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SJIG; and (earlier) Jingle <note>Before this specification was accepted as a Jabber Enhancement Proposal, it was discussed on the semi-private &lt;jingle@jabber.org&gt; mailing list; although that list is no longer used (the Standards-JIG list is the preferred discussion venue), for historical purposes it is publicly archived at &lt;<link url='http://mail.jabber.org/pipermail/jingle/'>http://mail.jabber.org/pipermail/jingle/</link>&gt;.</note> mailing lists.</p>
824
+  <p>The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ij&#228;s, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SJIG; and (earlier) Jingle <note>Before this specification was accepted as a XMPP Extension Protocol specification, it was discussed on the semi-private &lt;jingle@jabber.org&gt; mailing list; although that list is no longer used (the Standards-JIG list is the preferred discussion venue), for historical purposes it is publicly archived at &lt;<link url='http://mail.jabber.org/pipermail/jingle/'>http://mail.jabber.org/pipermail/jingle/</link>&gt;.</note> mailing lists.</p>
825 825
 </section1>
826 826
 </xep>

+ 3
- 3
xep-0172.xml View File

@@ -65,7 +65,7 @@
65 65
     <version>0.4</version>
66 66
     <date>2006-03-20</date>
67 67
     <initials>psa</initials>
68
-    <remark><p>To reflect use of dedicated namespace, (1) changed JEP type from Informational to Standards Track and (2) updated XMPP Registrar Considerations.</p></remark>
68
+    <remark><p>To reflect use of dedicated namespace, (1) changed document type from Informational to Standards Track and (2) updated XMPP Registrar Considerations.</p></remark>
69 69
   </revision>
70 70
   <revision>
71 71
     <version>0.3</version>
@@ -83,7 +83,7 @@
83 83
     <version>0.1</version>
84 84
     <date>2006-01-24</date>
85 85
     <initials>psa</initials>
86
-    <remark><p>Initial JEP version.</p></remark>
86
+    <remark><p>Initial version.</p></remark>
87 87
   </revision>
88 88
   <revision>
89 89
     <version>0.0.3</version>
@@ -365,7 +365,7 @@
365 365
   <p>A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particulat community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in <cite>XEP-0165</cite> in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.</p>
366 366
 </section1>
367 367
 <section1 topic='IANA Considerations' anchor='iana'>
368
-  <p>This JEP requires no interaction with &IANA;.</p>
368
+  <p>This document requires no interaction with &IANA;.</p>
369 369
 </section1>
370 370
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
371 371
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

+ 4
- 4
xep-0175.xml View File

@@ -31,7 +31,7 @@
31 31
     <version>0.1</version>
32 32
     <date>2006-02-09</date>
33 33
     <initials>psa</initials>
34
-    <remark><p>Initial JEP version; modified flow to remove unecessary challenge.</p></remark>
34
+    <remark><p>Initial version; modified flow to remove unecessary challenge.</p></remark>
35 35
   </revision>
36 36
   <revision>
37 37
     <version>0.0.1</version>
@@ -144,12 +144,12 @@
144 144
   </ol>
145 145
 </section1>
146 146
 <section1 topic='Security Considerations' anchor='security'>
147
-  <p>This JEP introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite>.</p>
147
+  <p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite>.</p>
148 148
 </section1>
149 149
 <section1 topic='IANA Considerations' anchor='iana'>
150
-  <p>This JEP requires no interaction with &IANA;.</p>
150
+  <p>This document requires no interaction with &IANA;.</p>
151 151
 </section1>
152 152
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
153
-  <p>This JEP requires no interaction with the &REGISTRAR;.</p>
153
+  <p>This document requires no interaction with the &REGISTRAR;.</p>
154 154
 </section1>
155 155
 </xep>

+ 7
- 7
xep-0176.xml View File

@@ -49,7 +49,7 @@
49 49
     <version>0.1</version>
50 50
     <date>2006-03-01</date>
51 51
     <initials>psa/jb</initials>
52
-    <remark>Initial JEP version (split from XEP-0166).</remark>
52
+    <remark>Initial version (split from XEP-0166).</remark>
53 53
   </revision>
54 54
 </header>
55 55
 <section1 topic='Introduction' anchor='intro'>
@@ -60,7 +60,7 @@
60 60
     <li>In Jingle, each candidate transport is sent in a separate IQ exchange (rather than sending all candidates at once as in draft-ietf-mmusic-ice); this approach takes advantage of the request-response semantics of the XMPP &IQ; stanza type and enables the parties to send higher-priority candidates earlier in the negotiation.</li>
61 61
     <li>Syntax from the Session Description Protocol (see &rfc4566;) is mapped to an XML syntax suitable for sending over the XMPP signalling channel.</li>
62 62
   </ul>
63
-  <p><em>Note: This JEP depends on the IETF's Interactive Connectivity Establishment (ICE) specification, which is a work in progress. Every effort has been made to keep this JEP synchronized with draft-ietf-mmusic-ice, for which the latest published version is 10 (hereafter referred to as "&ice10;"). The interested reader is referred to the &ice10; for a detailed description of the ICE methodology, which for the most part this JEP merely maps to XMPP syntax.</em></p>
63
+  <p><em>Note: This document depends on the IETF's Interactive Connectivity Establishment (ICE) specification, which is a work in progress. Every effort has been made to keep this document synchronized with draft-ietf-mmusic-ice, for which the latest published version is 10 (hereafter referred to as "&ice10;"). The interested reader is referred to the &ice10; for a detailed description of the ICE methodology, which for the most part this document merely maps to XMPP syntax.</em></p>
64 64
 </section1>
65 65
 <section1 topic='Requirements' anchor='reqs'>
66 66
   <p>The Jingle transport method defined herein is designed to meet the following requirements:</p>
@@ -102,7 +102,7 @@
102 102
     ]]></example>
103 103
   </section2>
104 104
   <section2 topic='ICE Negotiation' anchor='protocol-negotiate'>
105
-    <p>If the responder provisionally accepts the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible. <note>Concurrent with negotiation of the ICE candidates, it is possible for the initiator and responder to negotiate which content types the session will include, which transport methods will be tried for each content type, etc. Those negotiation flows are shown in <cite>XEP-0166</cite>. This JEP specifies only negotiation of the ICE transport method.</note></p>
105
+    <p>If the responder provisionally accepts the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible. <note>Concurrent with negotiation of the ICE candidates, it is possible for the initiator and responder to negotiate which content types the session will include, which transport methods will be tried for each content type, etc. Those negotiation flows are shown in <cite>XEP-0166</cite>. This document specifies only negotiation of the ICE transport method.</note></p>
106 106
     <p>The candidate syntax and negotiation flow are described below.</p>
107 107
     <section3 topic='Syntax of Candidate Element' anchor='protocol-negotiate-candidate'>
108 108
       <p>The following is an example of the candidate format:</p>
@@ -425,15 +425,15 @@
425 425
 </section1>
426 426
 
427 427
 <section1 topic='IANA Considerations' anchor='iana'>
428
-  <p>This JEP requires no interaction with &IANA;.</p>
428
+  <p>This document requires no interaction with &IANA;.</p>
429 429
 </section1>
430 430
 
431
-<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
431
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
432 432
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
433 433
     <p>The &REGISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/ice' in its registry of protocol namespaces.</p>
434 434
   </section2>
435 435
   <section2 topic='Jingle Transport Methods' anchor='registrar-transports'>
436
-    <p>The Jabber Registrar shall include "http://jabber.org/protocol/jingle/transport/ice" in its registry of Jingle transport methods. The registry submission is as follows:</p>
436
+    <p>The XMPP Registrar shall include "http://jabber.org/protocol/jingle/transport/ice" in its registry of Jingle transport methods. The registry submission is as follows:</p>
437 437
     &REGPROCESS;
438 438
     <code><![CDATA[
439 439
 <transport>
@@ -447,7 +447,7 @@
447 447
     ]]></code>
448 448
   </section2>
449 449
   <section2 topic='Service Discovery Identity' anchor='registrar-disco'>
450
-    <p>The Jabber Registrar shall include a Service Discovery type of "stun" within the "proxy" category.</p>
450
+    <p>The XMPP Registrar shall include a Service Discovery type of "stun" within the "proxy" category.</p>
451 451
     <p>The registry submission is as follows:</p>
452 452
     <code><![CDATA[
453 453
 <category>

+ 1
- 1
xep-0182.xml View File

@@ -65,7 +65,7 @@
65 65
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
66 66
   <section2 topic='Application-Specific Error Conditions Registry' anchor='registrar-conditions'>
67 67
     <p>The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).</p>
68
-    <p>All application-specific error conditions that are defined in Jabber Enhancement Proposals MUST be included in this registry. Application-specific error conditions that are defined outside of the Jabber Software Foundation's standards process (see &xep0001;) MAY be included in this registry, but it is not required for them to be so registered.</p>
68
+    <p>All application-specific error conditions that are defined in XMPP Extension Protocol specifications MUST be included in this registry. Application-specific error conditions that are defined outside of the Jabber Software Foundation's standards process (see &xep0001;) MAY be included in this registry, but it is not required for them to be so registered.</p>
69 69
     <section3 topic='Registration Process' anchor='registrar-conditions-process'>
70 70
       &REGPROCESS;
71 71
       <code><![CDATA[

+ 2
- 2
xep-template.xml View File

@@ -36,7 +36,7 @@
36 36
   </revision>
37 37
 </header>
38 38
 <section1 topic='Introduction' anchor='intro'>
39
-  <p>This is a template for use in writing Jabber Enhancement Proposals. For detailed information about the XEP process and how to write an XMPP Extension Protocol specification, refer to "XEP-0001: XMPP Extension Protocols" and "XEP-0143: Guidelines for Authors of XMPP Extension Protocols".</p>
39
+  <p>This is a template for use in writing XMPP Extension Protocol specifications. For detailed information about the XEP process and how to write an XMPP Extension Protocol specification, refer to "XEP-0001: XMPP Extension Protocols" and "XEP-0143: Guidelines for Authors of XMPP Extension Protocols".</p>
40 40
 </section1>
41 41
 <section1 topic='Requirements' anchor='reqs'>
42 42
   <p>STRONGLY RECOMMENDED.</p>
@@ -62,7 +62,7 @@
62 62
 <section1 topic='IANA Considerations' anchor='iana'>
63 63
   <p>REQUIRED.</p>
64 64
 </section1>
65
-<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
65
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
66 66
   <p>REQUIRED.</p>
67 67
 </section1>
68 68
 <section1 topic='XML Schema' anchor='schema'>

Loading…
Cancel
Save