moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

corrections 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@51 4b5297f7-1745-476d-ba37-a9c6900126ab
xep-0352-v0.2
Peter Saint-Andre 2006-10-04 18:40:38 +00:00
parent 2d4af4ea52
commit 56412aa8c0
84 changed files with 249 additions and 273 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
all.sh
View File

@ -1,31 +1,20 @@
#!/bin/sh
# for each XEP, generates HTML file and IETF reference, then copies XML file
# also generates HTML for the README and template
# finally, copies the stylesheet, DTD, and schema
# usage: ./all.sh
# for one XEP, generates HTML file and IETF reference, then copies XML file
# usage: ./gen.sh xxxx
# (where xxxx is the 4-digit XEP number)
xeppath=/var/www/stage.xmpp.org/extensions
ls xep-0*.xml > tmp.txt
sed s/xep-\(.*\).xml/\1/ tmp.txt > nums.txt
rm tmp.txt
xsltproc xep.xsl xep-$1.xml > $xeppath/jep-$1.html
xsltproc ref.xsl xep-$1.xml > $xeppath/refs/reference.JSF.XEP-$1.xml
while read f
do
xsltproc xep.xsl xep-$f.xml > $xeppath/xep-$f.html
xsltproc ref.xsl xep-$f.xml > $xeppath/refs/reference.JSF.XEP-$f.xml
cp xep-$f.xml $xeppath/
done < nums.txt
cp xep-$1.xml $xeppath/
rm nums.txt
xsltproc xep.xsl xep-README.xml > $xeppath/README.html
xsltproc xep.xsl xep-template.xml > $xeppath/template.html
cp xep.dtd $xeppath/
cp xep.ent $xeppath/
cp xep.xsd $xeppath/
cp xep.xsl $xeppath/
cp *.dtd $xeppath/
cp *.ent $xeppath/
cp *.gif $xeppath/
cp *.html $xeppath/
cp *.shtml $xeppath/
cp *.xsd $xeppath/
# END

24
deferred.py
View File

@ -2,7 +2,7 @@
# File: deferred.py
# Version: 0.2
# Description: a script for setting a JEP to Deferred
# Description: a script for setting a XEP to Deferred
# Last Modified: 2006-04-24
# Author: Peter Saint-Andre (stpeter@jabber.org)
# License: public domain
@ -33,7 +33,7 @@ now = int(time.time())
# READ IN ARGS:
#
# 1. JEP number
# 1. XEP number
# 2. database user
# 3. database password
@ -43,7 +43,7 @@ dbpw = sys.argv[3];
jepfile = jepnum + '/jep-' + jepnum + '.xml'
# PARSE JEP HEADERS:
# PARSE XEP HEADERS:
#
# - title
# - abstract
@ -79,7 +79,7 @@ remark = getText(remarkNode.childNodes)
# name is $title
# type is $jeptype
# status is $jepstatus
# notes is "Version $version of JEP-$jepnum released $date."
# notes is "Version $version of XEP-$jepnum released $date."
# version is $version
# last_modified is $now
# abstract is $abstract
@ -87,7 +87,7 @@ remark = getText(remarkNode.childNodes)
db = MySQLdb.connect("localhost", dbuser, dbpw, "foundation")
cursor = db.cursor()
theNotes = "Version " + version + " of JEP-" + jepnum + " released " + date + "; consideration deferred because of inactivity."
theNotes = "Version " + version + " of XEP-" + jepnum + " released " + date + "; consideration deferred because of inactivity."
theLog = remark + " (" + initials + ")"
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) + "';"
cursor.execute(theStatement)
@ -97,15 +97,15 @@ result = cursor.fetchall()
#
# From: editor@jabber.org
# To: standards-jig@jabber.org
# Subject: DEFERRED: JEP-$jepnum ($title)
# Subject: DEFERRED: XEP-$jepnum ($title)
# Body:
# JEP-$jepnum ($title) has been Deferred because of inactivity.
# XEP-$jepnum ($title) has been Deferred because of inactivity.
#
# Abstract: $abstract
#
# URL: http://www.jabber.org/jeps/jep-$jepnum.html
#
# If and when a new revision of this JEP is published,
# If and when a new revision of this XEP is published,
# its status will be changed back to Experimental.
#
@ -115,14 +115,14 @@ fromaddr = "editor@jabber.org"
# for real...
toaddrs = "standards-jig@jabber.org"
thesubject = 'DEFERRED: JEP-' + jepnum + " (" + title + ")"
introline = 'JEP-' + jepnum + ' (' + title + ') has been Deferred because of inactivity.'
thesubject = 'DEFERRED: XEP-' + jepnum + " (" + title + ")"
introline = 'XEP-' + jepnum + ' (' + title + ') has been Deferred because of inactivity.'
abstractline = 'Abstract: ' + abstract
urlline = 'URL: http://www.jabber.org/jeps/jep-' + jepnum + '.html'
endline = 'If and when a new revision of this JEP is published, its status will be changed back to Experimental.'
endline = 'If and when a new revision of this XEP is published, its status will be changed back to Experimental.'
#msg = "From: %s\r\n" % fromaddr
msg = "From: JEP Editor <%s>\r\n" % fromaddr
msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr
msg = msg + "To: %s\r\n" % toaddrs
msg = msg + "Subject: %s\r\n" % thesubject
msg = msg + introline

16
fo.xsl
View File

@ -27,7 +27,7 @@
<page-sequence master-reference="jep_sequence">
<flow flow-name="xsl-region-body" font-family="serif" color="black" font-size="10pt">
<block space-before="1.5in" text-align="right" font-family="sans-serif" font-size="18pt">
JEP-<xsl:value-of select="/jep/header/number"/>
XEP-<xsl:value-of select="/jep/header/number"/>
</block>
<block text-align="right" font-family="sans-serif" font-size="18pt">
<xsl:value-of select="/jep/header/title"/>
@ -105,21 +105,9 @@
</flow>
</page-sequence>
<page-sequence master-reference="std_page" initial-page-number="1">
<!--<static-content flow-name="xsl-region-before" margin-top=".5in">
<block margin-left="1in" margin-right="1in" text-align-last="justify" font-size="9pt" font-family="sans-serif" color="silver">
<xsl:value-of select="/jep/header/customer"/>
<leader leader-pattern="space"/>
Requirements Proposal
</block>
<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">
<xsl:value-of select="/jep/header/title"/>
<leader leader-pattern="space"/>
<xsl:value-of select="/jep/header/revision[last()]/date"/>
</block>
</static-content>-->
<static-content flow-name="xsl-region-after">
<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">
IJEP-<xsl:value-of select="/jep/header/number"/>:<xsl:text> </xsl:text>
XEP-<xsl:value-of select="/jep/header/number"/>:<xsl:text> </xsl:text>
<xsl:value-of select="/jep/header/title"/>
<leader leader-pattern="space"/>
Page <page-number/> of <page-number-citation ref-id="lastpage"/>

2
gps_datum.html
View File

@ -4,7 +4,7 @@
</head>
<body>
<h1>GPS Datum Example</h1>
<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>
<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>
<p>BEGIN EXAMPLE</p>
<hr />
<p>This is an example of the differences in the datums you can use with a GPS.

22
inxep.py
View File

@ -2,7 +2,7 @@
# File: protojep.py
# Version: 0.1
# Description: a script for announcing proto-JEPs
# Description: a script for announcing proto-XEPs
# Last Modified: 2004-09-14
# Author: Peter Saint-Andre (stpeter@jabber.org)
# License: public domain
@ -30,13 +30,13 @@ def getText(nodelist):
# READ IN ARGS:
#
# 1. JEP filename (sans extension)
# 1. XEP filename (sans extension)
jepname = sys.argv[1];
jepfile = 'inbox/' + jepname + '.xml'
# PARSE JEP HEADERS:
# PARSE XEP HEADERS:
#
# - title
# - abstract
@ -70,9 +70,9 @@ remark = getText(remarkNode.childNodes)
#
# From: editor@jabber.org
# To: standards-jig@jabber.org
# Subject: LAST CALL: JEP-$jepnum ($title)
# Subject: LAST CALL: XEP-$jepnum ($title)
# Body:
# The JEP Editor has received a proposal for a new JEP.
# The XMPP Extensions Editor has received a proposal for a new XEP.
#
# Title: $title
#
@ -80,8 +80,8 @@ remark = getText(remarkNode.childNodes)
#
# URL: http://www.jabber.org/jeps/inbox/$jepname.html
#
# The Jabber Council will now consider whether to accept
# this proposal as a full JEP.
# The XMPP Council will now consider whether to accept
# this proposal as a full XEP.
#
fromaddr = "editor@jabber.org"
@ -90,15 +90,15 @@ fromaddr = "editor@jabber.org"
# for real...
toaddrs = "standards-jig@jabber.org"
thesubject = 'proto-JEP: ' + title
introline = 'The JEP Editor has received a proposal for a new JEP.'
thesubject = 'proto-XEP: ' + title
introline = 'The XMPP Extensions Editor has received a proposal for a new XEP.'
titleline = 'Title: ' + title
abstractline = 'Abstract: ' + abstract
urlline = 'URL: http://www.jabber.org/jeps/inbox/' + jepname + '.html'
actionline = 'The Jabber Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official JEP.'
actionline = 'The XMPP Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official XEP.'
#msg = "From: %s\r\n" % fromaddr
msg = "From: JEP Editor <%s>\r\n" % fromaddr
msg = "From: XEP Editor <%s>\r\n" % fromaddr
msg = msg + "To: %s\r\n" % toaddrs
msg = msg + "Subject: %s\r\n" % thesubject
msg = msg + introline

2
ipr-policy.shtml
View File

@ -79,7 +79,7 @@ License (&lt;http://creativecommons.org/by/2.5/&gt;).
</pre></blockquote>
<p><hr></p>
<h3>Notes</h3>
<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>
<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>
<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>
<h3>Acknowledgements</h3>
<p>Many thanks to Lawrence Lessig and Molly van Houweling for their assistance in formulating this policy.</p>

20
lastcall.py
View File

@ -2,7 +2,7 @@
# File: lastcall.py
# Version: 0.2
# Description: a script for announcing JEP Last Calls
# Description: a script for announcing Last Calls
# Last Modified: 2004-09-29
# Author: Peter Saint-Andre (stpeter@jabber.org)
# License: public domain
@ -33,7 +33,7 @@ now = int(time.time())
# READ IN ARGS:
#
# 1. JEP number
# 1. XEP number
# 2. end date
# 3. database user
# 4. database password
@ -45,7 +45,7 @@ dbpw = sys.argv[4];
jepfile = jepnum + '/jep-' + jepnum + '.xml'
# PARSE JEP HEADERS:
# PARSE XEP HEADERS:
#
# - title
# - abstract
@ -81,7 +81,7 @@ remark = getText(remarkNode.childNodes)
# name is $title
# type is $jeptype
# status is $jepstatus
# notes is "Version $version of JEP-$jepnum released $date."
# notes is "Version $version of XEP-$jepnum released $date."
# version is $version
# last_modified is $now
# abstract is $abstract
@ -89,7 +89,7 @@ remark = getText(remarkNode.childNodes)
db = MySQLdb.connect("localhost", dbuser, dbpw, "foundation")
cursor = db.cursor()
theNotes = "Version " + version + " of JEP-" + jepnum + " released " + date + "; Last Call ends " + enddate + "."
theNotes = "Version " + version + " of XEP-" + jepnum + " released " + date + "; Last Call ends " + enddate + "."
theLog = remark + " (" + initials + ")"
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) + "';"
cursor.execute(theStatement)
@ -99,10 +99,10 @@ result = cursor.fetchall()
#
# From: editor@jabber.org
# To: standards-jig@jabber.org
# Subject: LAST CALL: JEP-$jepnum ($title)
# Subject: LAST CALL: XEP-$jepnum ($title)
# Body:
# This message constitutes notice of a Last Call
# for JEP-$jepnum ($title).
# for XEP-$jepnum ($title).
#
# Abstract: $abstract
#
@ -118,14 +118,14 @@ fromaddr = "editor@jabber.org"
# for real...
toaddrs = "standards-jig@jabber.org"
thesubject = 'LAST CALL: JEP-' + jepnum + " (" + title + ")"
introline = 'This message constitutes notice of a Last Call for JEP-' + jepnum + ' (' + title + ').'
thesubject = 'LAST CALL: XEP-' + jepnum + " (" + title + ")"
introline = 'This message constitutes notice of a Last Call for XEP-' + jepnum + ' (' + title + ').'
abstractline = 'Abstract: ' + abstract
urlline = 'URL: http://www.jabber.org/jeps/jep-' + jepnum + '.html'
schedline = 'This Last Call begins today and shall end at the close of business on ' + enddate + '.'
#msg = "From: %s\r\n" % fromaddr
msg = "From: JEP Editor <%s>\r\n" % fromaddr
msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr
msg = msg + "To: %s\r\n" % toaddrs
msg = msg + "Subject: %s\r\n" % thesubject
msg = msg + introline

6
protopage.xsl
View File

@ -9,7 +9,7 @@
<html>
<head>
<title><xsl:value-of select='/jep/header/shortname'/></title>
<link rel='stylesheet' type='text/css' href='/jeps/jep.css' />
<link rel='stylesheet' type='text/css' href='/xmpp.css' />
<link rel='shortcut icon' type='image/x-icon' href='/favicon.ico' />
<link>
<xsl:attribute name='rel'><xsl:text>alternate</xsl:text></xsl:attribute>
@ -39,9 +39,9 @@
<xsl:value-of select='/jep/header/number'/>
<xsl:text>.html</xsl:text>
</xsl:attribute>
<xsl:text>JEP-</xsl:text><xsl:value-of select='/jep/header/number' />:<xsl:text> </xsl:text><xsl:value-of select='/jep/header/title' />
<xsl:text>XEP-</xsl:text><xsl:value-of select='/jep/header/number' />:<xsl:text> </xsl:text><xsl:value-of select='/jep/header/title' />
</a>
(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>
(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>
<xsl:variable name='schema.count' select='count(/jep/header/schemaloc)'/>
<xsl:if test='$schema.count &gt; 0'>

2
submit.shtml
View File

@ -8,7 +8,7 @@
<li><p>Contact the <a href="editor.shtml">XMPP Extensions Editor</a> so that he knows to expect your submission.</p></li>
<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>
<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>
<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>
<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>
</ol>
<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>
</div>

24
xep-0001.xml
View File

@ -35,43 +35,43 @@
<version>1.15</version>
<date>2004-11-02</date>
<initials>psa</initials>
<remark><p>Specified that a Standards Track JEP defines either (1) a wire protocol or (2) a protocol suite.</p></remark>
<remark><p>Specified that a Standards Track specification defines either (1) a wire protocol or (2) a protocol suite.</p></remark>
</revision>
<revision>
<version>1.14</version>
<date>2004-09-28</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>1.13</version>
<date>2004-08-24</date>
<initials>psa</initials>
<remark><p>Further specified the goals of the JEP process; mentioned Board-approved JEPs.</p></remark>
<remark><p>Further specified the goals of the standards process; mentioned Board-approved specifications.</p></remark>
</revision>
<revision>
<version>1.11</version>
<date>2004-07-14</date>
<initials>psa</initials>
<remark><p>Specified the procedure for changing a JEP from Historical to Standards Track.</p></remark>
<remark><p>Specified the procedure for changing a XEP from Historical to Standards Track.</p></remark>
</revision>
<revision>
<version>1.10</version>
<date>2004-03-24</date>
<initials>psa</initials>
<remark><p>Specified the procedure for acceptance of a proposal as a JEP; clarified the JEP types; completed editorial review.</p></remark>
<remark><p>Specified the procedure for acceptance of a proposal as a XEP; clarified the XEP types; completed editorial review.</p></remark>
</revision>
<revision>
<version>1.9</version>
<date>2003-12-22</date>
<initials>psa</initials>
<remark><p>Added rule about automatic deferral of inactive JEPs.</p></remark>
<remark><p>Added rule about automatic deferral of inactive specifications.</p></remark>
</revision>
<revision>
<version>1.8</version>
<date>2003-10-06</date>
<initials>psa</initials>
<remark><p>Clarified the definition of informational JEP.</p></remark>
<remark><p>Clarified the definition of informational specification.</p></remark>
</revision>
<revision>
<version>1.7</version>
@ -89,13 +89,13 @@
<version>1.5</version>
<date>2002-10-29</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>1.4</version>
<date>2002-01-16</date>
<initials>psa</initials>
<remark><p>Added information about the new "Experimental" state for Standards Track JEPs and made appropriate changes to the JEP process.</p></remark>
<remark><p>Added information about the new "Experimental" state for Standards Track specifications and made appropriate changes to the standards process.</p></remark>
</revision>
<revision>
<version>1.3.1</version>
@ -107,19 +107,19 @@
<version>1.3</version>
<date>2001-10-23</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>1.2</version>
<date>2001-09-27</date>
<initials>psa</initials>
<remark><p>(1) Added information about expiration dates; (2) Added a status of Deprecated to Standards Track JEPs.</p></remark>
<remark><p>(1) Added information about expiration dates; (2) Added a status of Deprecated to Standards Track specifications.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2001-09-09</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>1.0</version>

2
xep-0002.xml
View File

@ -37,6 +37,6 @@
<section1 topic='Explanation'>
<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>
<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>
<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>
<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>
</section1>
</xep>

2
xep-0005.xml
View File

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

4
xep-0006.xml
View File

@ -35,7 +35,7 @@
<version>1.1</version>
<date>2002-05-08</date>
<initials>psa</initials>
<remark>Changed Status to Obsolete per approval of JEP-0019.</remark>
<remark>Changed Status to Obsolete per approval of XEP-0019.</remark>
</revision>
<revision>
<version>1.0</version>
@ -91,6 +91,6 @@
<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>
</section1>
<section1 topic='History'>
<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>
<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>
</section1>
</xep>

2
xep-0007.xml
View File

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

4
xep-0008.xml
View File

@ -33,13 +33,13 @@
<version>0.3</version>
<date>2005-06-16</date>
<initials>psa</initials>
<remark>Coincident with publication of JEP-0153, changed type to Historical.</remark>
<remark>Coincident with publication of XEP-0153, changed type to Historical.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-05-06</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>0.1</version>

4
xep-0010.xml
View File

@ -23,7 +23,7 @@
<version>1.1</version>
<date>2002-05-08</date>
<initials>psa</initials>
<remark>Changed Status to Obsolete per approval of JEP-0019.</remark>
<remark>Changed Status to Obsolete per approval of XEP-0019.</remark>
</revision>
<revision>
<version>1.0</version>
@ -38,7 +38,7 @@
<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>
</section1>
<section1 topic='Deliverables'>
<p>The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council as a JEP):</p>
<p>The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):</p>
<section2 topic='Requirements'>
<p>A set of requirements that the proposed protocol should fulfill.</p>
</section2>

14
xep-0011.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Jabber Browsing</title>
<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>
<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>
&LEGALNOTICE;
<number>0011</number>
<status>Deprecated</status>
@ -18,7 +18,7 @@
</dependencies>
<supersedes/>
<supersededby>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</supersededby>
<shortname>iq-browse</shortname>
&jer;
@ -58,7 +58,7 @@
<version>0.2</version>
<date>2002-01-04</date>
<initials>jkm</initials>
<remark>Updated to JEP format and revised description.</remark>
<remark>Updated to XML format and revised description.</remark>
</revision>
<revision>
<version>0.1</version>
@ -297,7 +297,7 @@
</tr>
</table>
<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>
<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>
<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>
</section1>
<section1 topic='The jabber:iq:browse Namespace'>
<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 @@
<p>There are no security features or concerns related to this proposal.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<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>
<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>
</section1>
<section1 topic='XML Schema'>
<code><![CDATA[
@ -468,6 +468,6 @@
]]></code>
</section1>
<section1 topic='Future Considerations'>
<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>
<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>
</section1>
</xep>

2
xep-0012.xml
View File

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

2
xep-0014.xml
View File

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

4
xep-0015.xml
View File

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

6
xep-0018.xml
View File

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

30
xep-0019.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Streamlining the JIGs</title>
<abstract>This JEP proposes to streamline the existing Jabber Interest Groups (JIGs).</abstract>
<abstract>This document proposes to streamline the existing Jabber Interest Groups (JIGs).</abstract>
&LEGALNOTICE;
<number>0019</number>
<status>Active</status>
@ -38,39 +38,39 @@
</revision>
</header>
<section1 topic="Introduction">
<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>
<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>
</section1>
<section1 topic="The Problem">
<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>
<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>
<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>
<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>
<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>
<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>
<p>In other words, an honest assessment forces us to conclude that the JIGs are not working.</p>
</section1>
<section1 topic="Analysis and Possible Solutions">
<p>I see several possible solutions to the JIG problem:</p>
<ol>
<li>"Crack the whip" -- encourage and cajole the existing JIGs into becoming more active, and energetically manage them so that they produce JEPs.</li>
<li>"Crack the whip" -- encourage and cajole the existing JIGs into becoming more active, and energetically manage them so that they produce specifications.</li>
<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>
<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>
</ol>
<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>
<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>
<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>
<p>I see several reasons why the JIGs are not working:</p>
<ol>
<li>The Jabber community right now is too small to be split up successfully into smaller interest groups.</li>
<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>
<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>
<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>
</ol>
<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>
<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>
</section1>
<section1 topic="Proposed Solution">
<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>
<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>
<ol>
<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>
<li>Rely on individuals and small, ad-hoc groups to create JEPs.</li>
<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>
<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>
<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>
<li>Rely on individuals and small, ad-hoc groups to create specifications.</li>
<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>
<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>
</ol>
<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>
<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>
</section1>
</xep>

4
xep-0021.xml
View File

@ -16,7 +16,7 @@
<type>Standards Track</type>
<jig>Standards</jig>
<supersedes>None</supersedes>
<supersededby>JEP-0060</supersededby>
<supersededby>XEP-0060</supersededby>
<shortname>None</shortname>
<author>
<firstname>Robert</firstname>
@ -28,7 +28,7 @@
<version>0.2</version>
<date>2003-04-22</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>0.1</version>

4
xep-0022.xml
View File

@ -270,7 +270,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
<section1 topic='IANA Considerations'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<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>
</section1>
@ -315,7 +315,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
<section1 topic='Open Issues'>
<ol>
<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>
<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>
</ol>
</section1>

12
xep-0023.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Message Expiration</title>
<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>
<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>
&LEGALNOTICE;
<number>0023</number>
<status>Deprecated</status>
@ -18,7 +18,7 @@
</dependencies>
<supersedes/>
<supersededby>
<spec>JEP-0079</spec>
<spec>XEP-0079</spec>
</supersededby>
<shortname>x-expire</shortname>
<schemaloc>
@ -41,7 +41,7 @@
<version>1.2</version>
<date>2004-10-18</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>1.1</version>
@ -121,10 +121,10 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
<p>There are no security features or concerns related to this proposal.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
<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>
<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>
</section1>
<section1 topic='XML Schema'>
@ -168,7 +168,7 @@ SEND: &lt;message to='sabine@gnu.mine.nu' id='msg811'&gt;
<section1 topic='Open Issues'>
<ol>
<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>
<li>A physical, time-based TTL is not implemented by this JEP, and would not be possible across systems without synchronized time.</li>
<li>A physical, time-based TTL is not implemented by this document, and would not be possible across systems without synchronized time.</li>
</ol>
</section1>

4
xep-0024.xml
View File

@ -14,7 +14,7 @@
<type>Standards Track</type>
<jig>Standards</jig>
<supersedes>None</supersedes>
<supersededby>JEP-0060</supersededby>
<supersededby>XEP-0060</supersededby>
<shortname>None</shortname>
<author>
<firstname>DJ</firstname>
@ -32,7 +32,7 @@
<version>0.2</version>
<date>2003-04-22</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>0.1</version>

2
xep-0025.xml
View File

@ -18,7 +18,7 @@
</dependencies>
<supersedes/>
<supersededby>
<spec>JEP-0124</spec>
<spec>XEP-0124</spec>
</supersededby>
<shortname>httppoll</shortname>
&hildjj;

16
xep-0026.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Internationalization (I18N)</title>
<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>
<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>
&LEGALNOTICE;
<number>0026</number>
<status>Retracted</status>
@ -27,7 +27,7 @@
<version>0.2</version>
<date>2003-11-05</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>0.1</version>
@ -86,20 +86,20 @@
&lt;body'&gt;Ich bin ein Berliner!&lt;/body'&gt;
&lt;/message&gt; </example>
<p>
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;.
An xml:lang tag can be put onto any XML element; for the purposes of this document, however, we will limit its usage to the four central Jabber elements: &lt;stream/&gt;, &lt;message/&gt;, &lt;iq/&gt; and &lt;presence/&gt;.
</p>
</section2>
<section2 topic='Client support'>
<p>
A client claiming to support this JEP has to initiate server connection slightly differently by putting an xml:lang attribute in the initial &lt;stream:stream&gt; element.
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.
</p>
<example caption='Jabber session initiated with Canadian French as default'>
&lt;?xml version="1.0" encoding="UTF-8" ?&gt;
&lt;stream:stream to='jabber.org' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='fr-CA'&gt; </example>
<p>
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.
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.
</p>
<example caption='Reply by an English-language Jabber server'>
&lt;stream:stream from='jabber.org' id='12345' xmlns='jabber:client'
@ -108,7 +108,7 @@
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.
</p>
<p>
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.
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.
</p>
<p>
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 @@
A compliant server must detect the xml:lang attribute in incoming &lt;stream:stream&gt; elements. The server then has to store this information for later use, i.e. it has to remember the default language for each active session.
</p>
<p>
Additionally, a compliant server must attach an xml:lang attribute to the reply &lt;stream:stream&gt; element sent in response to a newly initiated connection. This attribute should reflect the default language of that server, and is used to indicate to clients that the server implements this JEP.
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.
</p>
<p>
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 @@
<section2 topic='Service support'>
<p>
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>.
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>.
</p>
<example caption='Search form in English'>
&lt;iq from='users.jabber.org' type='result' id='4' xml:lang='en'&gt;

8
xep-0029.xml
View File

@ -27,7 +27,7 @@
<version>1.1</version>
<date>2003-10-03</date>
<initials>psa</initials>
<remark>Changed status to Retracted. This JEP is superseded by the XMPP Core memo defined by the IETF's XMPP Working Group.</remark>
<remark>Changed status to Retracted. This document is superseded by the XMPP Core memo defined by the IETF's XMPP Working Group.</remark>
</revision>
<revision>
<version>1.0</version>
@ -51,7 +51,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<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>
<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>
</section1>
<section1 topic='JIDs'>
<p>JIDs consist of three main parts:</p>
@ -104,14 +104,14 @@
<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>
</section2>
<section2 topic='Limited Resources'>
<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>
<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>
<ol>
<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>
<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>
<li>There exist denial of service attacks stemming from an unlimited resource length.</li>
</ol>
<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>
<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>
<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>
</section2>
</section1>
</xep>

2
xep-0032.xml
View File

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

6
xep-0035.xml
View File

@ -9,7 +9,7 @@
<header>
<title>SSL/TLS Integration</title>
<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>
<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>
&LEGALNOTICE;
<number>0035</number>
<status>Retracted</status>
@ -29,7 +29,7 @@
<version>0.2</version>
<date>2003-11-05</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>0.1</version>
@ -121,7 +121,7 @@ S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
<section1 topic="Certificate-based authentication">
<p>TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile (see &xep0034;) and the EXTERNAL mechanism.</p>
<p>If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and <cite>JEP-0034</cite> for more information.</p>
<p>If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See &rfc2222; and <cite>XEP-0034</cite> for more information.</p>
<p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
</section1>

2
xep-0037.xml
View File

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

2
xep-0038.xml
View File

@ -232,7 +232,7 @@
<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>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>JANA shall register the namespace <tt>http://jabber.org/protocol/icon-styles</tt> as an official feature category.</p>
<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>
</section1>

3
xep-0039.xml
View File

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

8
xep-0042.xml
View File

@ -13,9 +13,9 @@
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards</jig>
<dependencies>JEP-0004 (OPTIONAL), JEP-0011 (RECOMMENDED) JEP-0029 (REQUIRED)</dependencies>
<dependencies>XEP-0004 (OPTIONAL), XEP-0011 (RECOMMENDED) XEP-0029 (REQUIRED)</dependencies>
<supersedes>None</supersedes>
<supersededby>JEP-0065</supersededby>
<supersededby>XEP-0065</supersededby>
<shortname>JOBS</shortname>
<author>
<firstname>Matthew</firstname>
@ -27,7 +27,7 @@
<version>0.5</version>
<date>2003-04-11</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>0.4</version>
@ -58,7 +58,7 @@
<section2 topic='Introduction'>
<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>
<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>
<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>
</section2>
<section2 topic='Design Concepts'>
<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>

8
xep-0043.xml
View File

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

4
xep-0045.xml
View File

@ -207,7 +207,7 @@
<version>0.23</version>
<date>2002-11-06</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>0.22</version>
@ -351,7 +351,7 @@
<version>0.5.1</version>
<date>2002-09-20</date>
<initials>psa</initials>
<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>
<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>
</revision>
<revision>
<version>0.5</version>

2
xep-0051.xml
View File

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

2
xep-0052.xml
View File

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

10
xep-0055.xml
View File

@ -15,7 +15,7 @@
<jig>Standards JIG</jig>
<dependencies>