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

corrections

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@51 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
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 #!/bin/sh
# for each XEP, generates HTML file and IETF reference, then copies XML file # for one XEP, generates HTML file and IETF reference, then copies XML file
# also generates HTML for the README and template # usage: ./gen.sh xxxx
# finally, copies the stylesheet, DTD, and schema # (where xxxx is the 4-digit XEP number)
# usage: ./all.sh
xeppath=/var/www/stage.xmpp.org/extensions xeppath=/var/www/stage.xmpp.org/extensions
ls xep-0*.xml > tmp.txt xsltproc xep.xsl xep-$1.xml > $xeppath/jep-$1.html
sed s/xep-\(.*\).xml/\1/ tmp.txt > nums.txt xsltproc ref.xsl xep-$1.xml > $xeppath/refs/reference.JSF.XEP-$1.xml
rm tmp.txt
while read f cp xep-$1.xml $xeppath/
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
rm nums.txt cp *.dtd $xeppath/
cp *.ent $xeppath/
xsltproc xep.xsl xep-README.xml > $xeppath/README.html cp *.gif $xeppath/
xsltproc xep.xsl xep-template.xml > $xeppath/template.html cp *.html $xeppath/
cp *.shtml $xeppath/
cp xep.dtd $xeppath/ cp *.xsd $xeppath/
cp xep.ent $xeppath/
cp xep.xsd $xeppath/
cp xep.xsl $xeppath/
# END # END

24
deferred.py
View File

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

16
fo.xsl
View File

@ -27,7 +27,7 @@
<page-sequence master-reference="jep_sequence"> <page-sequence master-reference="jep_sequence">
<flow flow-name="xsl-region-body" font-family="serif" color="black" font-size="10pt"> <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"> <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>
<block text-align="right" font-family="sans-serif" font-size="18pt"> <block text-align="right" font-family="sans-serif" font-size="18pt">
<xsl:value-of select="/jep/header/title"/> <xsl:value-of select="/jep/header/title"/>
@ -105,21 +105,9 @@
</flow> </flow>
</page-sequence> </page-sequence>
<page-sequence master-reference="std_page" initial-page-number="1"> <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"> <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"> <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"/> <xsl:value-of select="/jep/header/title"/>
<leader leader-pattern="space"/> <leader leader-pattern="space"/>
Page <page-number/> of <page-number-citation ref-id="lastpage"/> Page <page-number/> of <page-number-citation ref-id="lastpage"/>

2
gps_datum.html
View File

@ -4,7 +4,7 @@
</head> </head>
<body> <body>
<h1>GPS Datum Example</h1> <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> <p>BEGIN EXAMPLE</p>
<hr /> <hr />
<p>This is an example of the differences in the datums you can use with a GPS. <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 # File: protojep.py
# Version: 0.1 # Version: 0.1
# Description: a script for announcing proto-JEPs # Description: a script for announcing proto-XEPs
# Last Modified: 2004-09-14 # Last Modified: 2004-09-14
# Author: Peter Saint-Andre (stpeter@jabber.org) # Author: Peter Saint-Andre (stpeter@jabber.org)
# License: public domain # License: public domain
@ -30,13 +30,13 @@ def getText(nodelist):
# READ IN ARGS: # READ IN ARGS:
# #
# 1. JEP filename (sans extension) # 1. XEP filename (sans extension)
jepname = sys.argv[1]; jepname = sys.argv[1];
jepfile = 'inbox/' + jepname + '.xml' jepfile = 'inbox/' + jepname + '.xml'
# PARSE JEP HEADERS: # PARSE XEP HEADERS:
# #
# - title # - title
# - abstract # - abstract
@ -70,9 +70,9 @@ remark = getText(remarkNode.childNodes)
# #
# From: editor@jabber.org # From: editor@jabber.org
# To: standards-jig@jabber.org # To: standards-jig@jabber.org
# Subject: LAST CALL: JEP-$jepnum ($title) # Subject: LAST CALL: XEP-$jepnum ($title)
# Body: # 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 # Title: $title
# #
@ -80,8 +80,8 @@ remark = getText(remarkNode.childNodes)
# #
# URL: http://www.jabber.org/jeps/inbox/$jepname.html # URL: http://www.jabber.org/jeps/inbox/$jepname.html
# #
# The Jabber Council will now consider whether to accept # The XMPP Council will now consider whether to accept
# this proposal as a full JEP. # this proposal as a full XEP.
# #
fromaddr = "editor@jabber.org" fromaddr = "editor@jabber.org"
@ -90,15 +90,15 @@ fromaddr = "editor@jabber.org"
# for real... # for real...
toaddrs = "standards-jig@jabber.org" toaddrs = "standards-jig@jabber.org"
thesubject = 'proto-JEP: ' + title thesubject = 'proto-XEP: ' + title
introline = 'The JEP Editor has received a proposal for a new JEP.' introline = 'The XMPP Extensions Editor has received a proposal for a new XEP.'
titleline = 'Title: ' + title titleline = 'Title: ' + title
abstractline = 'Abstract: ' + abstract abstractline = 'Abstract: ' + abstract
urlline = 'URL: http://www.jabber.org/jeps/inbox/' + jepname + '.html' 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: %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 + "To: %s\r\n" % toaddrs
msg = msg + "Subject: %s\r\n" % thesubject msg = msg + "Subject: %s\r\n" % thesubject
msg = msg + introline msg = msg + introline

2
ipr-policy.shtml
View File

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

6
protopage.xsl
View File

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

24
xep-0001.xml
View File

@ -35,43 +35,43 @@
<version>1.15</version> <version>1.15</version>
<date>2004-11-02</date> <date>2004-11-02</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.14</version> <version>1.14</version>
<date>2004-09-28</date> <date>2004-09-28</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.13</version> <version>1.13</version>
<date>2004-08-24</date> <date>2004-08-24</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.11</version> <version>1.11</version>
<date>2004-07-14</date> <date>2004-07-14</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.10</version> <version>1.10</version>
<date>2004-03-24</date> <date>2004-03-24</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.9</version> <version>1.9</version>
<date>2003-12-22</date> <date>2003-12-22</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.8</version> <version>1.8</version>
<date>2003-10-06</date> <date>2003-10-06</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.7</version> <version>1.7</version>
@ -89,13 +89,13 @@
<version>1.5</version> <version>1.5</version>
<date>2002-10-29</date> <date>2002-10-29</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.4</version> <version>1.4</version>
<date>2002-01-16</date> <date>2002-01-16</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.3.1</version> <version>1.3.1</version>
@ -107,19 +107,19 @@
<version>1.3</version> <version>1.3</version>
<date>2001-10-23</date> <date>2001-10-23</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.2</version> <version>1.2</version>
<date>2001-09-27</date> <date>2001-09-27</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.1</version> <version>1.1</version>
<date>2001-09-09</date> <date>2001-09-09</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.0</version> <version>1.0</version>

2
xep-0002.xml
View File

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

2
xep-0005.xml
View File

@ -22,7 +22,7 @@
<version>1.1</version> <version>1.1</version>
<date>2002-05-08</date> <date>2002-05-08</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.0</version> <version>1.0</version>

4
xep-0006.xml
View File

@ -35,7 +35,7 @@
<version>1.1</version> <version>1.1</version>
<date>2002-05-08</date> <date>2002-05-08</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.0</version> <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> <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>
<section1 topic='History'> <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> </section1>
</xep> </xep>

2
xep-0007.xml
View File

@ -23,7 +23,7 @@
<version>1.1</version> <version>1.1</version>
<date>2002-05-08</date> <date>2002-05-08</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.0</version> <version>1.0</version>

4
xep-0008.xml
View File

@ -33,13 +33,13 @@
<version>0.3</version> <version>0.3</version>
<date>2005-06-16</date> <date>2005-06-16</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.2</version> <version>0.2</version>
<date>2003-05-06</date> <date>2003-05-06</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.1</version> <version>0.1</version>

4
xep-0010.xml
View File

@ -23,7 +23,7 @@
<version>1.1</version> <version>1.1</version>
<date>2002-05-08</date> <date>2002-05-08</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.0</version> <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> <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>
<section1 topic='Deliverables'> <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'> <section2 topic='Requirements'>
<p>A set of requirements that the proposed protocol should fulfill.</p> <p>A set of requirements that the proposed protocol should fulfill.</p>
</section2> </section2>

14
xep-0011.xml
View File

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

2
xep-0012.xml
View File

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

2
xep-0014.xml
View File

@ -23,7 +23,7 @@
<version>0.2</version> <version>0.2</version>
<date>2002-01-16</date> <date>2002-01-16</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.1</version> <version>0.1</version>

4
xep-0015.xml
View File

@ -29,7 +29,7 @@
<version>0.3</version> <version>0.3</version>
<date>2002-04-16</date> <date>2002-04-16</date>
<initials>cwc</initials> <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>
<revision> <revision>
<version>0.2</version> <version>0.2</version>
@ -47,7 +47,7 @@
<version>1.0</version> <version>1.0</version>
<date>2002-01-16</date> <date>2002-01-16</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.9</version> <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> <p>There are no security features or concerns related to this proposal.</p>
</section1> </section1>
<section1 topic="IANA Considerations"> <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>
<section1 topic="Jabber Registrar Considerations"> <section1 topic="XMPP Registrar Considerations">
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p> <p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
</section1> </section1>
</xep> </xep>

30
xep-0019.xml
View File

@ -7,7 +7,7 @@
<xep> <xep>
<header> <header>
<title>Streamlining the JIGs</title> <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; &LEGALNOTICE;
<number>0019</number> <number>0019</number>
<status>Active</status> <status>Active</status>
@ -38,39 +38,39 @@
</revision> </revision>
</header> </header>
<section1 topic="Introduction"> <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>
<section1 topic="The Problem"> <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>&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 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>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 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>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> <p>In other words, an honest assessment forces us to conclude that the JIGs are not working.</p>
</section1> </section1>
<section1 topic="Analysis and Possible Solutions"> <section1 topic="Analysis and Possible Solutions">
<p>I see several possible solutions to the JIG problem:</p> <p>I see several possible solutions to the JIG problem:</p>
<ol> <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>"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> <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> </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>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> <p>I see several reasons why the JIGs are not working:</p>
<ol> <ol>
<li>The Jabber community right now is too small to be split up successfully into smaller interest groups.</li> <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>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> </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>
<section1 topic="Proposed Solution"> <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> <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>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 JEPs.</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 JEPs before they are submitted to the Jabber Council.</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 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>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> </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> </section1>
</xep> </xep>

4
xep-0021.xml
View File

@ -16,7 +16,7 @@
<type>Standards Track</type> <type>Standards Track</type>
<jig>Standards</jig> <jig>Standards</jig>
<supersedes>None</supersedes> <supersedes>None</supersedes>
<supersededby>JEP-0060</supersededby> <supersededby>XEP-0060</supersededby>
<shortname>None</shortname> <shortname>None</shortname>
<author> <author>
<firstname>Robert</firstname> <firstname>Robert</firstname>
@ -28,7 +28,7 @@
<version>0.2</version> <version>0.2</version>
<date>2003-04-22</date> <date>2003-04-22</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.1</version> <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'> <section1 topic='IANA Considerations'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </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> <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> </section1>
@ -315,7 +315,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
<section1 topic='Open Issues'> <section1 topic='Open Issues'>
<ol> <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> </ol>
</section1> </section1>

12
xep-0023.xml
View File

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

4
xep-0024.xml
View File

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

2
xep-0025.xml
View File

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

16
xep-0026.xml
View File

@ -7,7 +7,7 @@
<xep> <xep>
<header> <header>
<title>Internationalization (I18N)</title> <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; &LEGALNOTICE;
<number>0026</number> <number>0026</number>
<status>Retracted</status> <status>Retracted</status>
@ -27,7 +27,7 @@
<version>0.2</version> <version>0.2</version>
<date>2003-11-05</date> <date>2003-11-05</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
@ -86,20 +86,20 @@
&lt;body'&gt;Ich bin ein Berliner!&lt;/body'&gt; &lt;body'&gt;Ich bin ein Berliner!&lt;/body'&gt;
&lt;/message&gt; </example> &lt;/message&gt; </example>
<p> <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> </p>
</section2> </section2>
<section2 topic='Client support'> <section2 topic='Client support'>
<p> <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> </p>
<example caption='Jabber session initiated with Canadian French as default'> <example caption='Jabber session initiated with Canadian French as default'>
&lt;?xml version="1.0" encoding="UTF-8" ?&gt; &lt;?xml version="1.0" encoding="UTF-8" ?&gt;
&lt;stream:stream to='jabber.org' xmlns='jabber:client' &lt;stream:stream to='jabber.org' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xml:lang='fr-CA'&gt; </example> xmlns:stream='http://etherx.jabber.org/streams' xml:lang='fr-CA'&gt; </example>
<p> <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> </p>
<example caption='Reply by an English-language Jabber server'> <example caption='Reply by an English-language Jabber server'>
&lt;stream:stream from='jabber.org' id='12345' xmlns='jabber:client' &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. 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>
<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>
<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. 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. 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>
<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>
<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. 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'> <section2 topic='Service support'>
<p> <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> </p>
<example caption='Search form in English'> <example caption='Search form in English'>
&lt;iq from='users.jabber.org' type='result' id='4' xml:lang='en'&gt; &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> <version>1.1</version>
<date>2003-10-03</date> <date>2003-10-03</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>1.0</version> <version>1.0</version>
@ -51,7 +51,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction'> <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>
<section1 topic='JIDs'> <section1 topic='JIDs'>
<p>JIDs consist of three main parts:</p> <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> <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>
<section2 topic='Limited Resources'> <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> <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>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>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> <li>There exist denial of service attacks stemming from an unlimited resource length.</li>
</ol> </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>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> </section2>
</section1> </section1>
</xep> </xep>

2
xep-0032.xml
View File

@ -22,7 +22,7 @@
<version>0.4</version> <version>0.4</version>
<date>2003-09-02</date> <date>2003-09-02</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.3</version> <version>0.3</version>

6
xep-0035.xml
View File

@ -9,7 +9,7 @@
<header> <header>
<title>SSL/TLS Integration</title> <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; &LEGALNOTICE;
<number>0035</number> <number>0035</number>
<status>Retracted</status> <status>Retracted</status>
@ -29,7 +29,7 @@
<version>0.2</version> <version>0.2</version>
<date>2003-11-05</date> <date>2003-11-05</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
@ -121,7 +121,7 @@ S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
<section1 topic="Certificate-based authentication"> <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>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> <p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
</section1> </section1>

2
xep-0037.xml
View File

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

3
xep-0039.xml
View File

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

8
xep-0042.xml
View File

@ -13,9 +13,9 @@
<status>Retracted</status> <status>Retracted</status>
<type>Standards Track</type> <type>Standards Track</type>
<jig>Standards</jig> <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> <supersedes>None</supersedes>
<supersededby>JEP-0065</supersededby> <supersededby>XEP-0065</supersededby>
<shortname>JOBS</shortname> <shortname>JOBS</shortname>
<author> <author>
<firstname>Matthew</firstname> <firstname>Matthew</firstname>
@ -27,7 +27,7 @@
<version>0.5</version> <version>0.5</version>
<date>2003-04-11</date> <date>2003-04-11</date>
<initials>psa</initials> <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>
<revision> <revision>
<version>0.4</version> <version>0.4</version>
@ -58,7 +58,7 @@
<section2 topic='Introduction'> <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>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>
<section2 topic='Design Concepts'> <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> <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 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> 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> <ol>
<li>Be able to request the available schemas</li> <li>Be able to request the available schemas</li>
<li>Perform near SQL-like data manipulation</li> <li>Perform near SQL-like data manipulation</li>
</ol> </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 restricted to such uses. It may be used with any data storage
system that can be broken down to a simple table, column/row system that can be broken down to a simple table, column/row
format. for example comma delimited files.</p> format. for example comma delimited files.</p>
</section1> </section1>
<section1 topic='Prerequisites'> <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> must be aware of the following.</p>
<section2 topic='Namespace'> <section2 topic='Namespace'>
<p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link> <p>The current namespace of <link>http://openaether.org/projects/jabber_database.html</link>
will be used until this becomes a jep. Once officially accepted as will be used until this becomes a jep. Once officially accepted as
a jep and approved as final by the council, it will become a jep and approved as final by the council, it will become
<link>http://www.jabber.org/jeps/jep-0043.html</link>.</p> <link>http://www.xmpp.org/extensions/xep-0043.html</link>.</p>
</section2> </section2>
<section2 topic='Elements'> <section2 topic='Elements'>
<ul> <ul>

4
xep-0045.xml
View File

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

2
xep-0051.xml
View File

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

2
xep-0052.xml
View File

@ -63,7 +63,7 @@
<section1 topic='Use Cases'> <section1 topic='Use Cases'>
<p> <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. may enhance this to include searching and offering.
</p> </p>

10
xep-0055.xml
View File

@ -15,7 +15,7 @@
<jig>Standards JIG</jig> <jig>Standards JIG</jig>
<dependencies> <dependencies>
<spec>XMPP Core</spec> <spec>XMPP Core</spec>
<spec dep="SHOULD">JEP-0004</spec> <spec dep="SHOULD">XEP-0004</spec>
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
@ -132,7 +132,7 @@
</section2> </section2>
</section1> </section1>
<section1 topic='Extensibility' anchor='extensibility'> <section1 topic='Extensibility' anchor='extensibility'>
<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> <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>
<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> <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>
<example caption='Entity Requests Search Fields from Service'><![CDATA[ <example caption='Entity Requests Search Fields from Service'><![CDATA[
<iq type='get' <iq type='get'
@ -239,7 +239,7 @@
<p>There are no security features or concerns related to this proposal.</p> <p>There are no security features or concerns related to this proposal.</p>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The &REGISTRAR; shall include the following information in its registries.</p> <p>The &REGISTRAR; shall include the following information in its registries.</p>
@ -247,11 +247,11 @@
<p>The XMPP Registrar includes the 'jabber:iq:search' namespace in its registry of protocol namespaces.</p> <p>The XMPP Registrar includes the 'jabber:iq:search' namespace in its registry of protocol namespaces.</p>
</section2> </section2>
<section2 topic='Field Standardization' anchor='registrar-formtypes'> <section2 topic='Field Standardization' anchor='registrar-formtypes'>
<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> <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>
<code caption='Registry Submission'><![CDATA[ <code caption='Registry Submission'><![CDATA[
<form_type> <form_type>
<name>jabber:iq:search</name> <name>jabber:iq:search</name>
<doc>JEP-0055</doc> <doc>XEP-0055</doc>
<desc>Forms enabling directory searches.</desc> <desc>Forms enabling directory searches.</desc>
<field <field
var='first' var='first'

6
xep-0057.xml
View File

@ -7,7 +7,7 @@
<xep> <xep>
<header> <header>
<title>Extended Roster</title> <title>Extended Roster</title>
<abstract>This JEP defines a way to handle extended roster items.</abstract> <abstract>This document defines a way to handle extended roster items.</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0057</number> <number>0057</number>
<status>Retracted</status> <status>Retracted</status>
@ -26,7 +26,7 @@
<version>0.2</version> <version>0.2</version>
<date>2003-04-28</date> <date>2003-04-28</date>
<initials>psa</initials> <initials>psa</initials>
<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> <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>
</revision> </revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
@ -37,7 +37,7 @@
</header> </header>
<section1 topic="Introduction"> <section1 topic="Introduction">
<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> <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>
</section1> </section1>
<section1 topic="What we need to store"> <section1 topic="What we need to store">

4
xep-0066.xml
View File

@ -50,7 +50,7 @@
<version>1.2</version> <version>1.2</version>
<date>2004-04-13</date> <date>2004-04-13</date>
<initials>psa</initials> <initials>psa</initials>
<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> <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>
</revision> </revision>
<revision> <revision>
<version>1.1</version> <version>1.1</version>
@ -227,7 +227,7 @@
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The 'jabber:iq:oob' and 'jabber:x:oob' namespaces are included in the protocol namespaces registry maintained by the &REGISTRAR; (see &NAMESPACES;).</p> <p>The 'jabber:iq:oob' and 'jabber:x:oob' namespaces are included in the protocol namespaces registry maintained by the &REGISTRAR; (see &NAMESPACES;).</p>
</section1> </section1>
<section1 topic='XML Schemas' anchor='schemas'> <section1 topic='XML Schemas' anchor='schemas'>

4
xep-0067.xml
View File

@ -7,7 +7,7 @@
<xep> <xep>
<header> <header>
<title>Stock Data Transmission</title> <title>Stock Data Transmission</title>
<abstract>This JEP specifies a data format for stock data distribution in the Jabber community.</abstract> <abstract>This document specifies a data format for stock data distribution in the Jabber community.</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0067</number> <number>0067</number>
<status>Deferred</status> <status>Deferred</status>
@ -47,7 +47,7 @@
Usage of jabber/xmpp for stock data transmission would be a nice-to-have. This xep defines transmission of stock ticker values via XMPP based on publish/subscribe. A component, client or alike may publish stock data in this specified way, after creating a node. However, first of all a node on the pub/sub server must be created, this xep recommends creation of the node in the domain 'stocks/', with specific stock value published in the ticker name domain space, i.e. 'stocks/CATG.DE' or 'stocks/602345'. This xep uses the domain 'stocks/' for example data. Usage of jabber/xmpp for stock data transmission would be a nice-to-have. This xep defines transmission of stock ticker values via XMPP based on publish/subscribe. A component, client or alike may publish stock data in this specified way, after creating a node. However, first of all a node on the pub/sub server must be created, this xep recommends creation of the node in the domain 'stocks/', with specific stock value published in the ticker name domain space, i.e. 'stocks/CATG.DE' or 'stocks/602345'. This xep uses the domain 'stocks/' for example data.
</p> </p>
<p> <p>
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. 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.
</p> </p>
<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. <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.
</p></section1> </p></section1>

2
xep-0068.xml
View File

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

4
xep-0071.xml
View File

@ -820,13 +820,13 @@ That seems fine to me.
<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> <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>
</section2> </section2>
<section2 topic='XHTML Versioning' anchor='w3c-versions'> <section2 topic='XHTML Versioning' anchor='w3c-versions'>
<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> <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>
</section2> </section2>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/xhtml-im' in its registry of protocol namespaces.</p> <p>The &REGISTRAR; includes 'http://jabber.org/protocol/xhtml-im' in its registry of protocol namespaces.</p>
</section2> </section2>

6
xep-0072.xml
View File

@ -1039,7 +1039,7 @@
<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> <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>
</section2> </section2>
<section2 topic='SOAP Versioning' anchor='w3c-soapversions'> <section2 topic='SOAP Versioning' anchor='w3c-soapversions'>
<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> <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>
</section2> </section2>
<section2 topic='XML Versioning' anchor='w3c-xmlversions'> <section2 topic='XML Versioning' anchor='w3c-xmlversions'>
<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> <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 @@
<p>No interaction with &IANA; is required by this document.</p> <p>No interaction with &IANA; is required by this document.</p>
</section1> </section1>
<section1 topic="Jabber Registrar Considerations" anchor='registrar'> <section1 topic="XMPP Registrar Considerations" anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/soap' and 'http://jabber.org/protocol/soap#fault' in its registry of protocol namespaces.</p> <p>The &REGISTRAR; includes 'http://jabber.org/protocol/soap' and 'http://jabber.org/protocol/soap#fault' in its registry of protocol namespaces.</p>
</section2> </section2>
<section2 topic='Service Discovery Identity' anchor='registrar-disco'> <section2 topic='Service Discovery Identity' anchor='registrar-disco'>
<p>The Jabber Registrar includes a Service Discovery type of "soap" within the "automation" category.</p> <p>The XMPP Registrar includes a Service Discovery type of "soap" within the "automation" category.</p>
<p>The registry submission is as follows:</p> <p>The registry submission is as follows:</p>
<code><![CDATA[ <code><![CDATA[
<category> <category>

2
xep-0075.xml
View File

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

8
xep-0077.xml
View File

@ -139,7 +139,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<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> <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>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<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> <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 @@
<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> <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>
<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> <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>
</ol> </ol>
<p>Support for extensibility via <cite>Data Forms</cite> is RECOMMENDED but is not required for compliance with this JEP.</p> <p>Support for extensibility via <cite>Data Forms</cite> is RECOMMENDED but is not required for compliance with this document.</p>
</section1> </section1>
<section1 topic='Redirection' anchor='redirect'> <section1 topic='Redirection' anchor='redirect'>
<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> <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 @@
<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> <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>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<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> <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>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

2
xep-0078.xml
View File

@ -285,7 +285,7 @@
<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> <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>
</section1> </section1>
<section1 topic='Expiration Date' anchor='expiration'> <section1 topic='Expiration Date' anchor='expiration'>
<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> <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>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<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> <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>

4
xep-0079.xml
View File

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

2
xep-0080.xml
View File

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

4
xep-0095.xml
View File

@ -308,13 +308,13 @@
</section2> </section2>
<section2 topic='Registries' anchor='registrar-reg'> <section2 topic='Registries' anchor='registrar-reg'>
<section3 topic='Profiles Registry' anchor='registrar-reg-profiles'> <section3 topic='Profiles Registry' anchor='registrar-reg-profiles'>
<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> <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>
<section4 topic='Process' anchor='registrar-reg-profiles-process'> <section4 topic='Process' anchor='registrar-reg-profiles-process'>
&REGPROCESS; &REGPROCESS;
<code><![CDATA[ <code><![CDATA[
<profile> <profile>
<name>The profile name</name> <name>The profile name</name>
<doc>The JEP or other document that defines the profile</doc> <doc>The specification that defines the profile</doc>
<desc>A natural-language description of the profile</desc> <desc>A natural-language description of the profile</desc>
</profile> </profile>
]]></code> ]]></code>

10
xep-0097.xml
View File

@ -31,8 +31,8 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction'> <section1 topic='Introduction'>
<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> <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>
<p>What this JEP will cover:</p> <p>What this document will cover:</p>
<ul> <ul>
<li>Sending iCal data</li> <li>Sending iCal data</li>
<li>Receiving iCal data</li> <li>Receiving iCal data</li>
@ -87,7 +87,7 @@
DTSTART:20030422T220000Z DTSTART:20030422T220000Z
DTEND:20030422T230000Z DTEND:20030422T230000Z
SEQUENCE:3 SEQUENCE:3
SUMMARY:JEPs SUMMARY:XEPs
LOCATION:foundation@conference.jabber.org LOCATION:foundation@conference.jabber.org
CATEGORIES:JSF CATEGORIES:JSF
CLASS:PUBLIC CLASS:PUBLIC
@ -115,10 +115,10 @@
<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> <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>
</section1> </section1>
<section1 topic='IANA Considerations'> <section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA)</p> <p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA)</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations'> <section1 topic='XMPP Registrar Considerations'>
<p>The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this JEP.</p> <p>The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this document.</p>
</section1> </section1>
<section1 topic='Formal Definition'> <section1 topic='Formal Definition'>
<section2 topic='Schema'> <section2 topic='Schema'>

4
xep-0099.xml
View File

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

2
xep-0103.xml
View File

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

2
xep-0104.xml
View File

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

12
xep-0107.xml
View File

@ -7,7 +7,7 @@
<xep> <xep>
<header> <header>
<title>User Mood</title> <title>User Mood</title>
<abstract>This JEP defines a protocol for communicating information about user moods.</abstract> <abstract>This document defines an XMPP protocol extension for communicating information about user moods.</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0107</number> <number>0107</number>
<status>Draft</status> <status>Draft</status>
@ -69,7 +69,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>This JEP defines an extension mechanism for capturing "extended presence" data about user moods.</p> <p>This document defines an extension mechanism for capturing "extended presence" data about user moods.</p>
</section1> </section1>
<section1 topic='Protocol' anchor='proto'> <section1 topic='Protocol' anchor='proto'>
<section2 topic='Data Format' anchor='proto-format'> <section2 topic='Data Format' anchor='proto-format'>
@ -77,7 +77,7 @@
<code><![CDATA[ <code><![CDATA[
<mood xmlns='http://jabber.org/protocol/mood'> <mood xmlns='http://jabber.org/protocol/mood'>
<happy/> <happy/>
<text>Yay, the mood JEP has been approved!</text> <text>Yay, the mood document has been approved!</text>
</mood> </mood>
]]></code> ]]></code>
<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> <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 @@
<happy> <happy>
<ecstatic xmlns='http://ik.nu/ralphm'/> <ecstatic xmlns='http://ik.nu/ralphm'/>
</happy> </happy>
<text>Yay, the mood JEP has been approved!</text> <text>Yay, the mood document has been approved!</text>
</mood> </mood>
]]></code> ]]></code>
</section2> </section2>
@ -171,7 +171,7 @@
<body>Cool!</body> <body>Cool!</body>
<mood xmlns='http://jabber.org/protocol/mood'> <mood xmlns='http://jabber.org/protocol/mood'>
<happy/> <happy/>
<text>Yay, the mood JEP has been published!</text> <text>Yay, the mood document has been published!</text>
<x xmlns='jabber:x:oob'> <x xmlns='jabber:x:oob'>
<url>http://www.xmpp.org/extensions/xep-0107.html</url> <url>http://www.xmpp.org/extensions/xep-0107.html</url>
</x> </x>
@ -271,7 +271,7 @@
<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> <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>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

2
xep-0109.xml
View File

@ -27,7 +27,7 @@
<version>0.2</version> <version>0.2</version>
<date>2003-08-12</date> <date>2003-08-12</date>
<initials>rn</initials> <initials>rn</initials>
<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> <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>
</revision> </revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>

2
xep-0111.xml
View File

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

2
xep-0116.xml
View File

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

2
xep-0118.xml
View File

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

12
xep-0120.xml
View File

@ -67,7 +67,7 @@
<section2 topic='Protocol Basics'> <section2 topic='Protocol Basics'>
<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> <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>
<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> <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>
<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> <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>
<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> <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>
</section2> </section2>
<section2 topic='Discovering Support'> <section2 topic='Discovering Support'>
@ -223,20 +223,20 @@
<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> <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>
</section1> </section1>
<section1 topic='Internationalization Considerations'> <section1 topic='Internationalization Considerations'>
<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> <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>
</section1> </section1>
<section1 topic='IANA Considerations'> <section1 topic='IANA Considerations'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='Jabber Registrar Considerations'> <section1 topic='XMPP Registrar Considerations'>
<section2 topic='Namespaces'> <section2 topic='Namespaces'>
<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> <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>
</section2> </section2>
<section2 topic='Registries'> <section2 topic='Registries'>
<p>The Jabber Registrar shall maintain a registry of infobit keynames and associated information.</p> <p>The XMPP Registrar shall maintain a registry of infobit keynames and associated information.</p>
<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> <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>
<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> <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>
<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> <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>
<p>In addition to the key name, the following data may be provided (but is not required) for each bit:</p> <p>In addition to the key name, the following data may be provided (but is not required) for each bit:</p>
<ol> <ol>
<li>datatype -- provide only if well-defined; otherwise assume string</li> <li>datatype -- provide only if well-defined; otherwise assume string</li>

2
xep-0121.xml
View File

@ -59,7 +59,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction'> <section1 topic='Introduction'>
<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> <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>
</section1> </section1>
<section1 topic='Dublin Core Metadata Terms'> <section1 topic='Dublin Core Metadata Terms'>
<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> <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>

2
xep-0125.xml
View File

@ -29,7 +29,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction'> <section1 topic='Introduction'>
<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> <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>
</section1> </section1>
<section1 topic='vCard Mapping'> <section1 topic='vCard Mapping'>
<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> <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>

2
xep-0128.xml
View File

@ -63,7 +63,7 @@
</query> </query>
</iq>]]></code> </iq>]]></code>
<p>Note: A &lt;field/&gt; element MAY contain more than one &lt;value/&gt; child if appropriate.</p> <p>Note: A &lt;field/&gt; element MAY contain more than one &lt;value/&gt; child if appropriate.</p>
<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> <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>
<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> <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>
</section1> </section1>
<section1 topic='Examples' anchor='examples'> <section1 topic='Examples' anchor='examples'>

2
xep-0129.xml
View File

@ -214,7 +214,7 @@
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<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> <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>
</section1> </section1>
</xep> </xep>

2
xep-0131.xml
View File

@ -178,7 +178,7 @@
</section1> </section1>
<section1 topic='Header Definitions' anchor='headers'> <section1 topic='Header Definitions' anchor='headers'>
<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> <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>
<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> <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>
<section2 topic='Classification' anchor='headers-classification'> <section2 topic='Classification' anchor='headers-classification'>
<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> <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>
</section2> </section2>

2
xep-0134.xml
View File

@ -97,7 +97,7 @@
<p>The core strength of Jabber technologies is the streaming of relatively small XML fragments between presence-aware network endpoints. As is usually the case, our greatest strength is also our greatest weakness. Thus XMPP is not optimized for binary data, large XML files, multimedia streaming, or other such applications.</p> <p>The core strength of Jabber technologies is the streaming of relatively small XML fragments between presence-aware network endpoints. As is usually the case, our greatest strength is also our greatest weakness. Thus XMPP is not optimized for binary data, large XML files, multimedia streaming, or other such applications.</p>
<p><em>Meaning</em></p> <p><em>Meaning</em></p>
<p>It's not a bad thing that we don't solve the problems of exchanging binary data, streaming multimedia, or transferring large XML files, because other protocols and technologies have addressed those domains. But it's important to recognize what we do well and what we don't. For example, sending base64-encoded binary data, streaming voice or video, or consistently large stanzas in the Jabber band <p>It's not a bad thing that we don't solve the problems of exchanging binary data, streaming multimedia, or transferring large XML files, because other protocols and technologies have addressed those domains. But it's important to recognize what we do well and what we don't. For example, sending base64-encoded binary data, streaming voice or video, or consistently large stanzas in the Jabber band
<note>There are no hard-and-fast rules regarding a reasonable upper limit on the average XML stanza. (Note the use of both 'reasonable' and 'average' in that sentence.) In reality, there is a continuum of stanza sizes, and different sizes may be appropriate for different types of XMPP applications and deployments. While sending 2 gigabyte or 2 megabyte stanzas is wrong in the current context of Jabber technologies, we cannot legitimately say that a 2 kilobyte, 20 kilobyte, or even 200 kilobyte stanza is unreasonable. Is the stanza sent over an open network with current server implementations, or over a closed network with specially tuned servers and clients? Does the application generate one such stanza every second, every minute, every hour? Considerations of this kind help us determine if the use of XMPP is "reasonable" in some sense. However, when protocol extensions are defined in 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> <note>There are no hard-and-fast rules regarding a reasonable upper limit on the average XML stanza. (Note the use of both 'reasonable' and 'average' in that sentence.) In reality, there is a continuum of stanza sizes, and different sizes may be appropriate for different types of XMPP applications and deployments. While sending 2 gigabyte or 2 megabyte stanzas is wrong in the current context of Jabber technologies, we cannot legitimately say that a 2 kilobyte, 20 kilobyte, or even 200 kilobyte stanza is unreasonable. Is the stanza sent over an open network with current server implementations, or over a closed network with specially tuned servers and clients? Does the application generate one such stanza every second, every minute, every hour? Considerations of this kind help us determine if the use of XMPP is "reasonable" in some sense. However, when protocol extensions are defined in XMPP Extension Protocols, the XMPP Council will require clear explanation of design choices and reasonable stanza size limits if the extension will generally require what might be considered larger than normal stanzas.</note>
is probably not a good idea, and applications that would depend on such behavior are better designed to communicate their data out of band.</p> is probably not a good idea, and applications that would depend on such behavior are better designed to communicate their data out of band.</p>
<p><em>Examples</em></p> <p><em>Examples</em></p>
<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> <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>

10
xep-0137.xml
View File

@ -52,7 +52,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<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> <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>
</section1> </section1>
<section1 topic='Requirements' anchor='requirements'> <section1 topic='Requirements' anchor='requirements'>
<p>This proposal addresses the following requirements:</p> <p>This proposal addresses the following requirements:</p>
@ -243,10 +243,10 @@
</section2> </section2>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>This JEP introduces no security concerns beyond those specified in <cite>XEP-0060</cite> and the relevant Stream Initiation profile in use.</p> <p>This document introduces no security concerns beyond those specified in <cite>XEP-0060</cite> and the relevant Stream Initiation profile in use.</p>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar.namespaces'> <section2 topic='Protocol Namespaces' anchor='registrar.namespaces'>
@ -254,7 +254,7 @@
</section2> </section2>
<section2 topic='Data Form Validation Datatypes' anchor='registrar.xdata-validate'> <section2 topic='Data Form Validation Datatypes' anchor='registrar.xdata-validate'>
<p>The XMPP Registrar includes 'sipub:' in its registry of Data Forms Validation Datatype Prefixes.</p> <p>The XMPP Registrar includes 'sipub:' in its registry of Data Forms Validation Datatype Prefixes.</p>
<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> <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>
<code caption='Data Forms Validation Datatypes Registry Submission'><![CDATA[ <code caption='Data Forms Validation Datatypes Registry Submission'><![CDATA[
<datatype> <datatype>
<name>sipub:file-transfer</name> <name>sipub:file-transfer</name>
@ -277,7 +277,7 @@
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The protocol documented by this schema is defined in The protocol documented by this schema is defined in
XEP-0137: http://www.jabber.org/xeps/xep-0137.html XEP-0137: http://www.xmpp.org/extensions/xep-0137.html
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>

2
xep-0141.xml
View File

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

10
xep-0144.xml
View File

@ -7,7 +7,7 @@
<xep> <xep>
<header> <header>
<title>Roster Item Exchange</title> <title>Roster Item Exchange</title>
<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> <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>
&LEGALNOTICE; &LEGALNOTICE;
<number>0144</number> <number>0144</number>
<status>Draft</status> <status>Draft</status>
@ -66,7 +66,7 @@
<version>0.1</version> <version>0.1</version>
<date>2004-09-29</date> <date>2004-09-29</date>
<initials>psa</initials> <initials>psa</initials>
<remark>Initial JEP version.</remark> <remark>Initial version.</remark>
</revision> </revision>
<revision> <revision>
<version>0.0.2</version> <version>0.0.2</version>
@ -82,7 +82,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<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> <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>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<p>XEP-0093 did not define the requirements for roster item exchange. This section remedies that oversight.</p> <p>XEP-0093 did not define the requirements for roster item exchange. This section remedies that oversight.</p>
@ -92,7 +92,7 @@
<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> <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>
<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> <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>
</ol> </ol>
<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> <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>
</section1> </section1>
<section1 topic='Use Cases' anchor='usecases'> <section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Suggesting Roster Item Addition' anchor='add'> <section2 topic='Suggesting Roster Item Addition' anchor='add'>
@ -263,7 +263,7 @@
</section2> </section2>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

6
xep-0145.xml
View File

@ -40,7 +40,7 @@
<version>0.2</version> <version>0.2</version>
<date>2005-07-15</date> <date>2005-07-15</date>
<initials>psa</initials> <initials>psa</initials>
<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> <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>
</revision> </revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
@ -117,11 +117,11 @@
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<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>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p> <p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>

4
xep-0146.xml
View File

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

2
xep-0148.xml
View File

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

2
xep-0153.xml
View File

@ -48,7 +48,7 @@
<version>0.1</version> <version>0.1</version>
<date>2005-06-16</date> <date>2005-06-16</date>
<initials>psa</initials> <initials>psa</initials>
<remark>Initial JEP version.</remark> <remark>Initial version.</remark>
</revision> </revision>
<revision> <revision>
<version>0.0.3</version> <version>0.0.3</version>

2
xep-0154.xml
View File

@ -167,7 +167,7 @@
</ol> </ol>
</li> </li>
</ul> </ul>
<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> <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>
<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> <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>
<example caption='A Basic Example'><![CDATA[ <example caption='A Basic Example'><![CDATA[
<profile xmlns='http://jabber.org/protocol/profile'> <profile xmlns='http://jabber.org/protocol/profile'>

6
xep-0155.xml
View File

@ -41,7 +41,7 @@
<version>0.6</version> <version>0.6</version>
<date>2006-07-13</date> <date>2006-07-13</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Specified that a client must re-initiate if it receives presence unavailable; changed JEP type to Standards Track.</p></remark> <remark><p>Specified that a client must re-initiate if it receives presence unavailable; changed document type to Standards Track.</p></remark>
</revision> </revision>
<revision> <revision>
<version>0.5</version> <version>0.5</version>
@ -71,7 +71,7 @@
<version>0.1</version> <version>0.1</version>
<date>2005-07-14</date> <date>2005-07-14</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Initial JEP version.</p></remark> <remark><p>Initial version.</p></remark>
</revision> </revision>
<revision> <revision>
<version>0.0.1</version> <version>0.0.1</version>
@ -492,7 +492,7 @@ However, if the receiving party assumes that the other client will <em>not</em>
<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> <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>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Service Discovery Features' anchor='registrar-features'> <section2 topic='Service Discovery Features' anchor='registrar-features'>

4
xep-0156.xml
View File

@ -39,7 +39,7 @@
<version>0.1</version> <version>0.1</version>
<date>2005-09-08</date> <date>2005-09-08</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Initial JEP version.</p></remark> <remark><p>Initial version.</p></remark>
</revision> </revision>
<revision> <revision>
<version>0.0.3</version> <version>0.0.3</version>
@ -106,7 +106,7 @@ _xmppconnect IN TXT "_xmpp-client-wap=http://wap.jabber.org/connector.cgi"
<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> <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>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='DNS TXT Records Registry' anchor='registrar-dnstxt'> <section2 topic='DNS TXT Records Registry' anchor='registrar-dnstxt'>

2
xep-0166.xml
View File

@ -821,6 +821,6 @@ PENDING o---------------------+ |
</section2> </section2>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>
<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> <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>
</section1> </section1>
</xep> </xep>

6
xep-0172.xml
View File

@ -65,7 +65,7 @@
<version>0.4</version> <version>0.4</version>
<date>2006-03-20</date> <date>2006-03-20</date>
<initials>psa</initials> <initials>psa</initials>
<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> <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>
</revision> </revision>
<revision> <revision>
<version>0.3</version> <version>0.3</version>
@ -83,7 +83,7 @@
<version>0.1</version> <version>0.1</version>
<date>2006-01-24</date> <date>2006-01-24</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Initial JEP version.</p></remark> <remark><p>Initial version.</p></remark>
</revision> </revision>
<revision> <revision>
<version>0.0.3</version> <version>0.0.3</version>
@ -365,7 +365,7 @@
<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> <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>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>

8
xep-0175.xml
View File

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

14
xep-0176.xml
View File

@ -49,7 +49,7 @@
<version>0.1</version> <version>0.1</version>
<date>2006-03-01</date> <date>2006-03-01</date>
<initials>psa/jb</initials> <initials>psa/jb</initials>
<remark>Initial JEP version (split from XEP-0166).</remark> <remark>Initial version (split from XEP-0166).</remark>
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
@ -60,7 +60,7 @@
<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> <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>
<li>Syntax from the Session Description Protocol (see &rfc4566;) is mapped to an XML syntax suitable for sending over the XMPP signalling channel.</li> <li>Syntax from the Session Description Protocol (see &rfc4566;) is mapped to an XML syntax suitable for sending over the XMPP signalling channel.</li>
</ul> </ul>
<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> <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>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<p>The Jingle transport method defined herein is designed to meet the following requirements:</p> <p>The Jingle transport method defined herein is designed to meet the following requirements:</p>
@ -102,7 +102,7 @@
]]></example> ]]></example>
</section2> </section2>
<section2 topic='ICE Negotiation' anchor='protocol-negotiate'> <section2 topic='ICE Negotiation' anchor='protocol-negotiate'>
<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> <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>
<p>The candidate syntax and negotiation flow are described below.</p> <p>The candidate syntax and negotiation flow are described below.</p>
<section3 topic='Syntax of Candidate Element' anchor='protocol-negotiate-candidate'> <section3 topic='Syntax of Candidate Element' anchor='protocol-negotiate-candidate'>
<p>The following is an example of the candidate format:</p> <p>The following is an example of the candidate format:</p>
@ -425,15 +425,15 @@
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/ice' in its registry of protocol namespaces.</p> <p>The &REGISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/ice' in its registry of protocol namespaces.</p>
</section2> </section2>
<section2 topic='Jingle Transport Methods' anchor='registrar-transports'> <section2 topic='Jingle Transport Methods' anchor='registrar-transports'>
<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> <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>
&REGPROCESS; &REGPROCESS;
<code><![CDATA[ <code><![CDATA[
<transport> <transport>
@ -447,7 +447,7 @@
]]></code> ]]></code>
</section2> </section2>
<section2 topic='Service Discovery Identity' anchor='registrar-disco'> <section2 topic='Service Discovery Identity' anchor='registrar-disco'>
<p>The Jabber Registrar shall include a Service Discovery type of "stun" within the "proxy" category.</p> <p>The XMPP Registrar shall include a Service Discovery type of "stun" within the "proxy" category.</p>
<p>The registry submission is as follows:</p> <p>The registry submission is as follows:</p>
<code><![CDATA[ <code><![CDATA[
<category> <category>

2
xep-0182.xml
View File

@ -65,7 +65,7 @@
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Application-Specific Error Conditions Registry' anchor='registrar-conditions'> <section2 topic='Application-Specific Error Conditions Registry' anchor='registrar-conditions'>
<p>The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).</p> <p>The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).</p>
<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> <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>
<section3 topic='Registration Process' anchor='registrar-conditions-process'> <section3 topic='Registration Process' anchor='registrar-conditions-process'>
&REGPROCESS; &REGPROCESS;
<code><![CDATA[ <code><![CDATA[

4
xep-template.xml
View File

@ -36,7 +36,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<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> <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>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<p>STRONGLY RECOMMENDED.</p> <p>STRONGLY RECOMMENDED.</p>
@ -62,7 +62,7 @@
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p>REQUIRED.</p> <p>REQUIRED.</p>
</section1> </section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>REQUIRED.</p> <p>REQUIRED.</p>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>