diff --git a/all.sh b/all.sh
index 192295e1..085a4aae 100755
--- a/all.sh
+++ b/all.sh
@@ -1,31 +1,20 @@
#!/bin/sh
-# for each XEP, generates HTML file and IETF reference, then copies XML file
-# also generates HTML for the README and template
-# finally, copies the stylesheet, DTD, and schema
-# usage: ./all.sh
+# for one XEP, generates HTML file and IETF reference, then copies XML file
+# usage: ./gen.sh xxxx
+# (where xxxx is the 4-digit XEP number)
xeppath=/var/www/stage.xmpp.org/extensions
-ls xep-0*.xml > tmp.txt
-sed s/xep-\(.*\).xml/\1/ tmp.txt > nums.txt
-rm tmp.txt
+xsltproc xep.xsl xep-$1.xml > $xeppath/jep-$1.html
+xsltproc ref.xsl xep-$1.xml > $xeppath/refs/reference.JSF.XEP-$1.xml
-while read f
-do
- xsltproc xep.xsl xep-$f.xml > $xeppath/xep-$f.html
- xsltproc ref.xsl xep-$f.xml > $xeppath/refs/reference.JSF.XEP-$f.xml
- cp xep-$f.xml $xeppath/
-done < nums.txt
+cp xep-$1.xml $xeppath/
-rm nums.txt
-
-xsltproc xep.xsl xep-README.xml > $xeppath/README.html
-xsltproc xep.xsl xep-template.xml > $xeppath/template.html
-
-cp xep.dtd $xeppath/
-cp xep.ent $xeppath/
-cp xep.xsd $xeppath/
-cp xep.xsl $xeppath/
+cp *.dtd $xeppath/
+cp *.ent $xeppath/
+cp *.gif $xeppath/
+cp *.html $xeppath/
+cp *.shtml $xeppath/
+cp *.xsd $xeppath/
# END
-
diff --git a/deferred.py b/deferred.py
index 11134f31..23acd8fb 100755
--- a/deferred.py
+++ b/deferred.py
@@ -2,7 +2,7 @@
# File: deferred.py
# Version: 0.2
-# Description: a script for setting a JEP to Deferred
+# Description: a script for setting a XEP to Deferred
# Last Modified: 2006-04-24
# Author: Peter Saint-Andre (stpeter@jabber.org)
# License: public domain
@@ -33,7 +33,7 @@ now = int(time.time())
# READ IN ARGS:
#
-# 1. JEP number
+# 1. XEP number
# 2. database user
# 3. database password
@@ -43,7 +43,7 @@ dbpw = sys.argv[3];
jepfile = jepnum + '/jep-' + jepnum + '.xml'
-# PARSE JEP HEADERS:
+# PARSE XEP HEADERS:
#
# - title
# - abstract
@@ -79,7 +79,7 @@ remark = getText(remarkNode.childNodes)
# name is $title
# type is $jeptype
# status is $jepstatus
-# notes is "Version $version of JEP-$jepnum released $date."
+# notes is "Version $version of XEP-$jepnum released $date."
# version is $version
# last_modified is $now
# abstract is $abstract
@@ -87,7 +87,7 @@ remark = getText(remarkNode.childNodes)
db = MySQLdb.connect("localhost", dbuser, dbpw, "foundation")
cursor = db.cursor()
-theNotes = "Version " + version + " of JEP-" + jepnum + " released " + date + "; consideration deferred because of inactivity."
+theNotes = "Version " + version + " of XEP-" + jepnum + " released " + date + "; consideration deferred because of inactivity."
theLog = remark + " (" + initials + ")"
theStatement = "UPDATE jeps SET name='" + title + "', type='" + jeptype + "', status='Deferred', notes='" + theNotes + "', version='" + str(version) + "', last_modified='" + str(now) + "', abstract='" + abstract + "', changelog='" + theLog + "' WHERE number='" + str(jepnum) + "';"
cursor.execute(theStatement)
@@ -97,15 +97,15 @@ result = cursor.fetchall()
#
# From: editor@jabber.org
# To: standards-jig@jabber.org
-# Subject: DEFERRED: JEP-$jepnum ($title)
+# Subject: DEFERRED: XEP-$jepnum ($title)
# Body:
-# JEP-$jepnum ($title) has been Deferred because of inactivity.
+# XEP-$jepnum ($title) has been Deferred because of inactivity.
#
# Abstract: $abstract
#
# URL: http://www.jabber.org/jeps/jep-$jepnum.html
#
-# If and when a new revision of this JEP is published,
+# If and when a new revision of this XEP is published,
# its status will be changed back to Experimental.
#
@@ -115,14 +115,14 @@ fromaddr = "editor@jabber.org"
# for real...
toaddrs = "standards-jig@jabber.org"
-thesubject = 'DEFERRED: JEP-' + jepnum + " (" + title + ")"
-introline = 'JEP-' + jepnum + ' (' + title + ') has been Deferred because of inactivity.'
+thesubject = 'DEFERRED: XEP-' + jepnum + " (" + title + ")"
+introline = 'XEP-' + jepnum + ' (' + title + ') has been Deferred because of inactivity.'
abstractline = 'Abstract: ' + abstract
urlline = 'URL: http://www.jabber.org/jeps/jep-' + jepnum + '.html'
-endline = 'If and when a new revision of this JEP is published, its status will be changed back to Experimental.'
+endline = 'If and when a new revision of this XEP is published, its status will be changed back to Experimental.'
#msg = "From: %s\r\n" % fromaddr
-msg = "From: JEP Editor <%s>\r\n" % fromaddr
+msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr
msg = msg + "To: %s\r\n" % toaddrs
msg = msg + "Subject: %s\r\n" % thesubject
msg = msg + introline
diff --git a/fo.xsl b/fo.xsl
index dda73c45..8c7f9491 100644
--- a/fo.xsl
+++ b/fo.xsl
@@ -27,7 +27,7 @@
The following example of GPS datum differences was kindly provided by Randy Steele of Apollo, Pennsylvania (URL: <http://www.nb.net/~resteele/>) and is archived here so that a permanent link is available from JEP-0080: User Geolocation. The following example of GPS datum differences was kindly provided by Randy Steele of Apollo, Pennsylvania (URL: <http://www.nb.net/~resteele/>) and is archived here so that a permanent link is available from XEP-0080: User Geolocation. BEGIN EXAMPLE This is an example of the differences in the datums you can use with a GPS.
diff --git a/inxep.py b/inxep.py
index ddfc72e4..324836d3 100755
--- a/inxep.py
+++ b/inxep.py
@@ -2,7 +2,7 @@
# File: protojep.py
# Version: 0.1
-# Description: a script for announcing proto-JEPs
+# Description: a script for announcing proto-XEPs
# Last Modified: 2004-09-14
# Author: Peter Saint-Andre (stpeter@jabber.org)
# License: public domain
@@ -30,13 +30,13 @@ def getText(nodelist):
# READ IN ARGS:
#
-# 1. JEP filename (sans extension)
+# 1. XEP filename (sans extension)
jepname = sys.argv[1];
jepfile = 'inbox/' + jepname + '.xml'
-# PARSE JEP HEADERS:
+# PARSE XEP HEADERS:
#
# - title
# - abstract
@@ -70,9 +70,9 @@ remark = getText(remarkNode.childNodes)
#
# From: editor@jabber.org
# To: standards-jig@jabber.org
-# Subject: LAST CALL: JEP-$jepnum ($title)
+# Subject: LAST CALL: XEP-$jepnum ($title)
# Body:
-# The JEP Editor has received a proposal for a new JEP.
+# The XMPP Extensions Editor has received a proposal for a new XEP.
#
# Title: $title
#
@@ -80,8 +80,8 @@ remark = getText(remarkNode.childNodes)
#
# URL: http://www.jabber.org/jeps/inbox/$jepname.html
#
-# The Jabber Council will now consider whether to accept
-# this proposal as a full JEP.
+# The XMPP Council will now consider whether to accept
+# this proposal as a full XEP.
#
fromaddr = "editor@jabber.org"
@@ -90,15 +90,15 @@ fromaddr = "editor@jabber.org"
# for real...
toaddrs = "standards-jig@jabber.org"
-thesubject = 'proto-JEP: ' + title
-introline = 'The JEP Editor has received a proposal for a new JEP.'
+thesubject = 'proto-XEP: ' + title
+introline = 'The XMPP Extensions Editor has received a proposal for a new XEP.'
titleline = 'Title: ' + title
abstractline = 'Abstract: ' + abstract
urlline = 'URL: http://www.jabber.org/jeps/inbox/' + jepname + '.html'
-actionline = 'The Jabber Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official JEP.'
+actionline = 'The XMPP Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official XEP.'
#msg = "From: %s\r\n" % fromaddr
-msg = "From: JEP Editor <%s>\r\n" % fromaddr
+msg = "From: XEP Editor <%s>\r\n" % fromaddr
msg = msg + "To: %s\r\n" % toaddrs
msg = msg + "Subject: %s\r\n" % thesubject
msg = msg + introline
diff --git a/ipr-policy.shtml b/ipr-policy.shtml
index 23f41d48..39982ae6 100755
--- a/ipr-policy.shtml
+++ b/ipr-policy.shtml
@@ -79,7 +79,7 @@ License (<http://creativecommons.org/by/2.5/>).
GPS Datum Example
-
1. For information about XMPP Extension Protocols, see <http://www.xmpp.org/extensions/> and JEP-0001.
+1. For information about XMPP Extension Protocols, see <http://www.xmpp.org/extensions/> and XEP-0001.
2. For information about intellectual property conservancies, see <http://www.creativecommons.org/concepts/#ip> and M. van Houweling, "Cultivating Open Information Platforms: A Land Trust Model." Journal of Telecommunications & High Technology Law 1, no. 1 (2002): 309-23.
Many thanks to Lawrence Lessig and Molly van Houweling for their assistance in formulating this policy.
diff --git a/lastcall.py b/lastcall.py index 1c35caa3..fd765484 100755 --- a/lastcall.py +++ b/lastcall.py @@ -2,7 +2,7 @@ # File: lastcall.py # Version: 0.2 -# Description: a script for announcing JEP Last Calls +# Description: a script for announcing Last Calls # Last Modified: 2004-09-29 # Author: Peter Saint-Andre (stpeter@jabber.org) # License: public domain @@ -33,7 +33,7 @@ now = int(time.time()) # READ IN ARGS: # -# 1. JEP number +# 1. XEP number # 2. end date # 3. database user # 4. database password @@ -45,7 +45,7 @@ dbpw = sys.argv[4]; jepfile = jepnum + '/jep-' + jepnum + '.xml' -# PARSE JEP HEADERS: +# PARSE XEP HEADERS: # # - title # - abstract @@ -81,7 +81,7 @@ remark = getText(remarkNode.childNodes) # name is $title # type is $jeptype # status is $jepstatus -# notes is "Version $version of JEP-$jepnum released $date." +# notes is "Version $version of XEP-$jepnum released $date." # version is $version # last_modified is $now # abstract is $abstract @@ -89,7 +89,7 @@ remark = getText(remarkNode.childNodes) db = MySQLdb.connect("localhost", dbuser, dbpw, "foundation") cursor = db.cursor() -theNotes = "Version " + version + " of JEP-" + jepnum + " released " + date + "; Last Call ends " + enddate + "." +theNotes = "Version " + version + " of XEP-" + jepnum + " released " + date + "; Last Call ends " + enddate + "." theLog = remark + " (" + initials + ")" theStatement = "UPDATE jeps SET name='" + title + "', type='" + jeptype + "', status='Proposed', notes='" + theNotes + "', version='" + str(version) + "', last_modified='" + str(now) + "', abstract='" + abstract + "', changelog='" + theLog + "' WHERE number='" + str(jepnum) + "';" cursor.execute(theStatement) @@ -99,10 +99,10 @@ result = cursor.fetchall() # # From: editor@jabber.org # To: standards-jig@jabber.org -# Subject: LAST CALL: JEP-$jepnum ($title) +# Subject: LAST CALL: XEP-$jepnum ($title) # Body: # This message constitutes notice of a Last Call -# for JEP-$jepnum ($title). +# for XEP-$jepnum ($title). # # Abstract: $abstract # @@ -118,14 +118,14 @@ fromaddr = "editor@jabber.org" # for real... toaddrs = "standards-jig@jabber.org" -thesubject = 'LAST CALL: JEP-' + jepnum + " (" + title + ")" -introline = 'This message constitutes notice of a Last Call for JEP-' + jepnum + ' (' + title + ').' +thesubject = 'LAST CALL: XEP-' + jepnum + " (" + title + ")" +introline = 'This message constitutes notice of a Last Call for XEP-' + jepnum + ' (' + title + ').' abstractline = 'Abstract: ' + abstract urlline = 'URL: http://www.jabber.org/jeps/jep-' + jepnum + '.html' schedline = 'This Last Call begins today and shall end at the close of business on ' + enddate + '.' #msg = "From: %s\r\n" % fromaddr -msg = "From: JEP Editor <%s>\r\n" % fromaddr +msg = "From: XMPP Extensions Editor <%s>\r\n" % fromaddr msg = msg + "To: %s\r\n" % toaddrs msg = msg + "Subject: %s\r\n" % thesubject msg = msg + introline diff --git a/protopage.xsl b/protopage.xsl index 8711ba4a..9c6580cc 100644 --- a/protopage.xsl +++ b/protopage.xsl @@ -9,7 +9,7 @@Contact the XMPP Extensions Editor so that he knows to expect your submission.
Write your proposal following the guidelines described in XEP-0143: Guidelines for Authors of XMPP Extension Protocols.
Email the XML file (or a URL for the file) to the XMPP Extensions Editor with a subject line of "ProtoJEP: [your title here]".
Email the XML file (or a URL for the file) to the XMPP Extensions Editor with a subject line of "ProtoXEP: [your title here]".
Note: It is the author's responsibility to provide a properly-formatted source file (see the template and CVS repository). Proposals submitted in HTML, TXT, MS Word, Open Document Format, etc. will be returned to the proposal author for proper formatting.
diff --git a/xep-0001.xml b/xep-0001.xml index d82db4e0..6f9b7026 100644 --- a/xep-0001.xml +++ b/xep-0001.xml @@ -35,43 +35,43 @@Specified that a Standards Track JEP defines either (1) a wire protocol or (2) a protocol suite.
Specified that a Standards Track specification defines either (1) a wire protocol or (2) a protocol suite.
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.
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.
Further specified the goals of the JEP process; mentioned Board-approved JEPs.
Further specified the goals of the standards process; mentioned Board-approved specifications.
Specified the procedure for changing a JEP from Historical to Standards Track.
Specified the procedure for changing a XEP from Historical to Standards Track.
Specified the procedure for acceptance of a proposal as a JEP; clarified the JEP types; completed editorial review.
Specified the procedure for acceptance of a proposal as a XEP; clarified the XEP types; completed editorial review.
Added rule about automatic deferral of inactive JEPs.
Added rule about automatic deferral of inactive specifications.
Clarified the definition of informational JEP.
Clarified the definition of informational specification.
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.
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.
Added information about the new "Experimental" state for Standards Track JEPs and made appropriate changes to the JEP process.
Added information about the new "Experimental" state for Standards Track specifications and made appropriate changes to the standards process.
(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.
(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.
(1) Added information about expiration dates; (2) Added a status of Deprecated to Standards Track JEPs.
(1) Added information about expiration dates; (2) Added a status of Deprecated to Standards Track specifications.
(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.
(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.
The main function of most JIGs is to produce acceptable XMPP extensions (delivered in the form of XMPP Extension Protocols or XEPs
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.
-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).
+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).
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.
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 (http://www.theoretic.com/identity/), 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.
+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 (http://www.theoretic.com/identity/), 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.
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
The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council as a JEP):
+The Whiteboarding JIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):
A set of requirements that the proposed protocol should fulfill.
Historically each category was used as the name of an element, and the type was an attribute, such as ]]>. The proper expression for all new implementations supporting this specification is to express the type information as attributes on a generic item element: ]]>. 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.
-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.
+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.
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).
@@ -422,10 +422,10 @@There are no security features or concerns related to this proposal.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:iq:browse' is already a registered protocol namespace.
+No action on the part of the ®ISTRAR; is necessary as a result of this document, since 'jabber:iq:browse' is already a registered protocol namespace.
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.
+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.
There are no security features or concerns related to this proposal.
No interaction with &IANA; is required as a result of this JEP.
+No interaction with &IANA; is required as a result of this document.
No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this JEP.
+No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this document.
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).
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).
&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).
-Unfortunately, it is widely recognized in the Jabber community that the JIGs are not working. Ten JIGs have been approved by the Jabber Council,
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.
+&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).
+Unfortunately, it is widely recognized in the Jabber community that the JIGs are not working. Ten JIGs have been approved by the Jabber Council,
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.
In other words, an honest assessment forces us to conclude that the JIGs are not working.
I see several possible solutions to the JIG problem:
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.
-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.
+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.
I see several reasons why the JIGs are not working:
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.
+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.
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:
+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:
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.
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.
This document requires no interaction with &IANA;.
No action on the part of the ®ISTRAR; is necessary as a result of this document, since 'jabber:x:event' is already a registered protocol namespace.
There are no security features or concerns related to this proposal.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
No action on the part of the ®ISTRAR; is necessary as a result of this JEP, since 'jabber:x:expire' is already a registered protocol namespace.
+No action on the part of the ®ISTRAR; is necessary as a result of this document, since 'jabber:x:expire' is already a registered protocol namespace.
- 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: <stream/>, <message/>, <iq/> and <presence/>. + 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: <stream/>, <message/>, <iq/> and <presence/>.
- A client claiming to support this JEP has to initiate server connection slightly differently by putting an xml:lang attribute in the initial <stream:stream> element. + A client claiming to support this document has to initiate server connection slightly differently by putting an xml:lang attribute in the initial <stream:stream> element.
- Servers not supporting this JEP will just ignore the additional attribute. Compliant server can be distinguished by the fact that their reply <stream:stream> 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 <stream:stream> 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.
- 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.
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 <stream:stream> 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.
- Additionally, a compliant server must attach an xml:lang attribute to the reply <stream:stream> 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 <stream:stream> 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.
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 @@
- 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 JEP-0004.
+ 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 XEP-0004.
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.
+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.
JIDs consist of three main parts:
@@ -104,14 +104,14 @@Resources identifiers are case-sensitive and are limited to 256 bytes. They may include any Unicode character greater than #x20, except #xFFFE and #xFFFF.
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:
+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:
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.
-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.
+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.
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.
-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 JEP-0034 for more information.
+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 XEP-0034 for more information.
Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.
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.
-JANA shall register the namespace http://jabber.org/protocol/icon-styles as an official feature category.
Also, JANA may choose to define IM-specific xml:lang "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.
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
The aim of this JEP is to define a process of connecting a sender to one or more receivers through a secondary TCP port.
+The aim of this document is to define a process of connecting a sender to one or more receivers through a secondary TCP port.
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.
diff --git a/xep-0043.xml b/xep-0043.xml index ee6576c6..ee8d7d4c 100644 --- a/xep-0043.xml +++ b/xep-0043.xml @@ -39,27 +39,27 @@ simple mechanism for a JID to read/write data that it has access to and specifying a model for those schemas to use in xml. -This JEP has two aims.
+This document has two aims.
Although designed for use with an RDBMS this JEP is not +
Although designed for use with an RDBMS this document is not restricted to such uses. It may be used with any data storage system that can be broken down to a simple table, column/row format. for example comma delimited files.
To understand the following sections of this JEP the reader +
To understand the following sections of this document the reader must be aware of the following.
The current namespace of http://openaether.org/projects/jabber_database.html will be used until this becomes a jep. Once officially accepted as a jep and approved as final by the council, it will become - http://www.jabber.org/jeps/jep-0043.html.
+ http://www.xmpp.org/extensions/xep-0043.html.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.
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.
Added DTDs; changed feature discovery to use <x/> 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.
Added DTDs; changed feature discovery to use <x/> 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.
- 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.
diff --git a/xep-0055.xml b/xep-0055.xml index 7bb82c2f..97da54a4 100644 --- a/xep-0055.xml +++ b/xep-0055.xml @@ -15,7 +15,7 @@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, Data Forms SHOULD be used; a host MUST NOT add new fields to the 'jabber:iq:search' namespace. Support for extensibility via Data Forms is RECOMMENDED, but is not required for compliance with this JEP.
+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, Data Forms SHOULD be used; a host MUST NOT add new fields to the 'jabber:iq:search' namespace. Support for extensibility via Data Forms is RECOMMENDED, but is not required for compliance with this document.
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.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall include the following information in its registries.
@@ -247,11 +247,11 @@The XMPP Registrar includes the 'jabber:iq:search' namespace in its registry of protocol namespaces.
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.
+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.
jabber:iq:search
- JEP-0055
+ XEP-0055
Forms enabling directory searches.
Extended Roster
- This JEP defines a way to handle extended roster items.
+ This document defines a way to handle extended roster items.
&LEGALNOTICE;
0057
Retracted
@@ -26,7 +26,7 @@
0.2
2003-04-28
psa
- 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.
+ 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.
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.
+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.
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.
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.
This document requires no interaction with &IANA;.
The 'jabber:iq:oob' and 'jabber:x:oob' namespaces are included in the protocol namespaces registry maintained by the ®ISTRAR; (see &NAMESPACES;).
-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.
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.
FORM_TYPE namespace or namespace derivative
- associated JEP or other document
+ associated specification
natural-language description of form type
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.
- 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.
+ 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.
This document requires no interaction with &IANA;.
The ®ISTRAR; includes 'http://jabber.org/protocol/xhtml-im' in its registry of protocol namespaces.
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 XML Protocol Working Group. To that end, revised versions of this specification will be announced on the W3C's public xml-dist-app@w3.org mailing list.
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.
+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.
Per RFC 3920, 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.
@@ -1100,12 +1100,12 @@No interaction with &IANA; is required by this document.
The ®ISTRAR; includes 'http://jabber.org/protocol/soap' and 'http://jabber.org/protocol/soap#fault' in its registry of protocol namespaces.
The Jabber Registrar includes a Service Discovery type of "soap" within the "automation" category.
+The XMPP Registrar includes a Service Discovery type of "soap" within the "automation" category.
The registry submission is as follows:
diff --git a/xep-0075.xml b/xep-0075.xml
index d7753f8e..653c833a 100644
--- a/xep-0075.xml
+++ b/xep-0075.xml
@@ -1330,7 +1330,7 @@
This JEP requires no interaction with the IANA.
+This document requires no interaction with the IANA.
This protocol defines one new namespace, 'jabber:iq:joap'.
diff --git a/xep-0077.xml b/xep-0077.xml index 5dee5f82..74a15227 100644 --- a/xep-0077.xml +++ b/xep-0077.xml @@ -139,7 +139,7 @@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.
+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.
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:
@@ -502,7 +502,7 @@Support for extensibility via Data Forms is RECOMMENDED but is not required for compliance with this JEP.
+Support for extensibility via Data Forms is RECOMMENDED but is not required for compliance with this document.
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 <instructions/> element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066; (see the Precedence Order section below for further details).
@@ -605,10 +605,10 @@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;.
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.
+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.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
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 RFC 3920. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both.
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.
+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.
Use of the 'jabber:iq:auth' method for client-server authentication is not as secure as SASL authentication (defined in RFC 3920). 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 <policy-violation/> stream error to the client.
diff --git a/xep-0079.xml b/xep-0079.xml index 67b292c5..9bb37c76 100644 --- a/xep-0079.xml +++ b/xep-0079.xml @@ -78,13 +78,13 @@Incorporated Standards JIG feedback; changed JEP type to Informational.
Incorporated Standards JIG feedback; changed document type to Informational.
The XMPP Registrar shall maintain a registry of stream initiation profiles, located at <http://www.jabber.org/registrar/si-profiles.html>. 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.
+The XMPP Registrar shall maintain a registry of stream initiation profiles, located at <http://www.jabber.org/registrar/si-profiles.html>. 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.
The profile name
- The JEP or other document that defines the profile
+ The specification that defines the profile
A natural-language description of the profile
]]>
diff --git a/xep-0097.xml b/xep-0097.xml
index 8aae76a5..5cf01ce8 100644
--- a/xep-0097.xml
+++ b/xep-0097.xml
@@ -31,8 +31,8 @@
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
What this JEP will cover:
+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
What this document will cover:
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.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA)
+This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this JEP.
+The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this document.
There is a need for consistent query behavior amongst XMPP &IQ; protocols. Currently 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 this standard will make other protocols easier to understand and implement by using a common core protocol.
@@ -381,7 +381,7 @@ RECIPIENT:In order to define an action protocol that uses the &QUERY; behavior defined in -this JEP, you must specify the following:
+this document, you must specify the following:This JEP defines an extension mechanism for capturing "extended presence" data about user moods.
+This document defines an extension mechanism for capturing "extended presence" data about user moods.
- Yay, the mood JEP has been approved!
+ Yay, the mood document has been approved!
]]>
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:
@@ -86,7 +86,7 @@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.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
At the request of the JEP author, changed status to Retracted.
At the request of the author, changed status to Retracted.
The "infobits" protocol defined herein provides a data format only. The container element is <info/>, which is qualified by the 'http://jabber.org/protocol/infobits' namespace. There is one allowable child of the <info/> element -- <bundle/> -- and one allowable child of the <bundle/> element -- <bit/>. In order to provide the relevant metadata, the <info/> element MAY contain an unbounded number of <bundle/> elements, each of which MAY contain an unbounded number of <bit/> elements.
Each <bundle/> element MUST possess a 'type' attribute, whose value specifies the aspect of reality to which the enclosed bits apply (e.g., geographical location). A <bundle/> 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).
-Each <bit/> element MUST possess a 'key' attribute, whose value specifies the name of the key (this MUST be an NMTOKEN as defined in &w3xml;). A <bit/> 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 <bit/> element SHOULD contain XML character data that specifies the relevant value of the 'key'. A <bundle/> element MAY contain more than one <bit/> 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).
+Each <bit/> element MUST possess a 'key' attribute, whose value specifies the name of the key (this MUST be an NMTOKEN as defined in &w3xml;). A <bit/> 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 <bit/> element SHOULD contain XML character data that specifies the relevant value of the 'key'. A <bundle/> element MAY contain more than one <bit/> 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).
Note well: 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.
Data provided via the infobits protocol MAY be world-readable. Access control considerations MUST be defined by any protocol that makes use of infobits.
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.
+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.
This document requires no interaction with &IANA;.
Upon advancement of this proposal to a status of Draft, the ®ISTRAR; shall add the 'http://jabber.org/protocol/infobits' namespace to its registry of official namespaces.
The Jabber Registrar shall maintain a registry of infobit keynames and associated information.
+The XMPP Registrar shall maintain a registry of infobit keynames and associated information.
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.
-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;).
-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.
+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;).
+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.
In addition to the key name, the following data may be provided (but is not required) for each bit:
&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 not meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the ®ISTRAR;, will specify additional infobits.
+&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 not meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in XMPP Extension Protocol specifications or direct submissions to the ®ISTRAR;, will specify additional infobits.
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).
diff --git a/xep-0125.xml b/xep-0125.xml index f82639af..77333671 100644 --- a/xep-0125.xml +++ b/xep-0125.xml @@ -29,7 +29,7 @@&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 not meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the ®ISTRAR;, will specify additional infobits.
+&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 not meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in XMPP Extension Protocol specifications or direct submissions to the ®ISTRAR;, will specify additional infobits.
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.)
diff --git a/xep-0128.xml b/xep-0128.xml index d061864a..92aa6377 100644 --- a/xep-0128.xml +++ b/xep-0128.xml @@ -63,7 +63,7 @@ ]]>Note: A <field/> element MAY contain more than one <value/> child if appropriate.
-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 <field/> element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".
+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 <field/> element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".
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 Service Discovery is that an entity must define its own identity only and must not define the identity of any children associated with the entity.
This document requires no interaction with &IANA;.
Upon advancement of this document to a status of Active, the ®ISTRAR; shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.
All public headers SHOULD be registered with the XMPP Registrar following the process specified in the XMPP Registrar Considerations 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.
-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.
+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.
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 Security Considerations for details).
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.
Meaning
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
-
Examples
&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.
diff --git a/xep-0137.xml b/xep-0137.xml index 36c2aade..6a7670cf 100644 --- a/xep-0137.xml +++ b/xep-0137.xml @@ -52,7 +52,7 @@&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.
+&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.
This proposal addresses the following requirements:
@@ -243,10 +243,10 @@This JEP introduces no security concerns beyond those specified in XEP-0060 and the relevant Stream Initiation profile in use.
+This document introduces no security concerns beyond those specified in XEP-0060 and the relevant Stream Initiation profile in use.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The XMPP Registrar includes 'sipub:' in its registry of Data Forms Validation Datatype Prefixes.
-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:
+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:
sipub:file-transfer
@@ -277,7 +277,7 @@
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
diff --git a/xep-0141.xml b/xep-0141.xml
index 8a6f9f5a..089c2d0d 100644
--- a/xep-0141.xml
+++ b/xep-0141.xml
@@ -40,7 +40,7 @@
0.2
2005-03-28
psa
- JEP Editor review: cleanup of text, examples, and schema.
+ Editorial review: cleanup of text, examples, and schema.
0.1
diff --git a/xep-0144.xml b/xep-0144.xml
index 536c9e6e..4192fe99 100644
--- a/xep-0144.xml
+++ b/xep-0144.xml
@@ -7,7 +7,7 @@
Roster Item Exchange
- This JEP defines a protocol for exchanging roster items, including the ability to suggest whether the item is to be added, deleted, or modified.
+ 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.
&LEGALNOTICE;
0144
Draft
@@ -66,7 +66,7 @@
0.1
2004-09-29
psa
- Initial JEP version.
+ Initial version.
0.0.2
@@ -82,7 +82,7 @@
- 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.
+ 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.
XEP-0093 did not define the requirements for roster item exchange. This section remedies that oversight.
@@ -92,7 +92,7 @@
- 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.
- 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.
- This JEP deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in RFC 3921), 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.
+ This document deliberately speaks of rosters and roster items, not presence subscriptions. Although rosters and subscriptions are closely connected (as explained in RFC 3921), 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.
@@ -263,7 +263,7 @@
- This JEP requires no interaction with &IANA;.
+ This document requires no interaction with &IANA;.
diff --git a/xep-0145.xml b/xep-0145.xml
index a6c5ebe9..f79be12d 100644
--- a/xep-0145.xml
+++ b/xep-0145.xml
@@ -40,7 +40,7 @@
0.2
2005-07-15
psa
- 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.
+ 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.
0.1
@@ -117,11 +117,11 @@
- No interaction with &IANA; is required as a result of this JEP.
+ No interaction with &IANA; is required as a result of this document.
- No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this JEP.
+ No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this document.
diff --git a/xep-0146.xml b/xep-0146.xml
index 4cbd9ab6..4c9c984e 100644
--- a/xep-0146.xml
+++ b/xep-0146.xml
@@ -658,10 +658,10 @@
-
+
- The Jabber Registrar includes 'http://jabber.org/protocol/rc' in its registry
+
The XMPP Registrar includes 'http://jabber.org/protocol/rc' in its registry
of protocol namespaces (see &NAMESPACES;).
diff --git a/xep-0148.xml b/xep-0148.xml
index 27b56ef6..c5009a3e 100644
--- a/xep-0148.xml
+++ b/xep-0148.xml
@@ -221,7 +221,7 @@
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
diff --git a/xep-0153.xml b/xep-0153.xml
index 3742a0af..27a76b45 100644
--- a/xep-0153.xml
+++ b/xep-0153.xml
@@ -48,7 +48,7 @@
0.1
2005-06-16
psa
- Initial JEP version.
+ Initial version.
0.0.3
diff --git a/xep-0154.xml b/xep-0154.xml
index 4166e25c..92f838ba 100644
--- a/xep-0154.xml
+++ b/xep-0154.xml
@@ -167,7 +167,7 @@
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 XEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (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 XEP-0068.
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 XEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (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 XEP-0068.
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:
Specified that a client must re-initiate if it receives presence unavailable; changed JEP type to Standards Track.
Specified that a client must re-initiate if it receives presence unavailable; changed document type to Standards Track.
Initial JEP version.
Initial version.
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 automatically (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.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
Initial JEP version.
Initial version.
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.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
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ä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
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ä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
To reflect use of dedicated namespace, (1) changed JEP type from Informational to Standards Track and (2) updated XMPP Registrar Considerations.
To reflect use of dedicated namespace, (1) changed document type from Informational to Standards Track and (2) updated XMPP Registrar Considerations.
Initial JEP version.
Initial version.
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 XEP-0165 in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
Initial JEP version; modified flow to remove unecessary challenge.
Initial version; modified flow to remove unecessary challenge.
This JEP introduces no security considerations or concerns above and beyond those discussed in RFC 3920.
+This document introduces no security considerations or concerns above and beyond those discussed in RFC 3920.
This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
This JEP requires no interaction with the ®ISTRAR;.
+This document requires no interaction with the ®ISTRAR;.
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.
+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.
The Jingle transport method defined herein is designed to meet the following requirements:
@@ -102,7 +102,7 @@ ]]>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.
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.
The candidate syntax and negotiation flow are described below.
The following is an example of the candidate format:
@@ -425,15 +425,15 @@This JEP requires no interaction with &IANA;.
+This document requires no interaction with &IANA;.
The ®ISTRAR; shall include 'http://jabber.org/protocol/jingle/transport/ice' in its registry of protocol namespaces.
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:
+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:
®PROCESS;
@@ -447,7 +447,7 @@
]]>
The Jabber Registrar shall include a Service Discovery type of "stun" within the "proxy" category.
+The XMPP Registrar shall include a Service Discovery type of "stun" within the "proxy" category.
The registry submission is as follows:
diff --git a/xep-0182.xml b/xep-0182.xml
index 486e90f8..fbcfd119 100644
--- a/xep-0182.xml
+++ b/xep-0182.xml
@@ -65,7 +65,7 @@
The XMPP Registrar maintains a registry of application-specific error conditions (see &APPERRORS;).
- 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.
+ 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.
®PROCESS;
- 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".
+ 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".
STRONGLY RECOMMENDED.
@@ -62,7 +62,7 @@
REQUIRED.
-
+
REQUIRED.