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

JEP to XEP 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@37 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 02:19:05 +00:00
parent a3136dfe3a
commit 39e3ea4b7d
10 changed files with 154 additions and 154 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
xep-0080.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>User Geolocation</title>
<abstract>This document defines an XMPP protocol extension for communicating information about the current geographical location of an entity.</abstract>
@ -15,13 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0060</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>geoloc</shortname>
<schemaloc>
<url>http://jabber.org/protocol/geoloc/geoloc.xsd</url>
<url>http://www.xmpp.org/schemas/geoloc.xsd</url>
</schemaloc>
&hildjj;
&stpeter;
@ -29,7 +29,7 @@
<version>1.3</version>
<date>2006-08-21</date>
<initials>psa</initials>
<remark><p>Folded in civil location from JEP-0112.</p></remark>
<remark><p>Folded in civil location from XEP-0112.</p></remark>
</revision>
<revision>
<version>1.2</version>
@ -65,13 +65,13 @@
<version>0.7</version>
<date>2004-04-25</date>
<initials>psa</initials>
<remark><p>Corrected several errors; added reference to JEP-0033.</p></remark>
<remark><p>Corrected several errors; added reference to XEP-0033.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2004-02-19</date>
<initials>psa</initials>
<remark><p>Reverted from infobits to geoloc elements; moved physical address protocol back to JEP-0112.</p></remark>
<remark><p>Reverted from infobits to geoloc elements; moved physical address protocol back to XEP-0112.</p></remark>
</revision>
<revision>
<version>0.5</version>
@ -83,7 +83,7 @@
<version>0.4</version>
<date>2003-09-08</date>
<initials>psa</initials>
<remark><p>Merged in contents of JEP-0112.</p></remark>
<remark><p>Merged in contents of XEP-0112.</p></remark>
</revision>
<revision>
<version>0.3</version>
@ -237,16 +237,16 @@
<tr>
<td>timestamp</td>
<td>xs:datetime</td>
<td>UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of &jep0082;)</td>
<td>UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of &xep0082;)</td>
<td>2004-02-19T21:12Z</td>
</tr>
</table>
<p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>The location information SHOULD be communicated by means of &jep0060; or the subset of pubsub defined in &jep0163;. Because location information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;, although an application MAY do so if necessary.</p>
<p>The location information SHOULD be communicated by means of &xep0060; or the subset of pubsub defined in &xep0163;. Because location information is not pure presence information and can change independently of the user's availability, it SHOULD NOT be provided as an extension to &PRESENCE;, although an application MAY do so if necessary.</p>
<section2 topic='Entity publishes location via pubsub' anchor='usecases-pubsub'>
<p>In order to provide information about one's location, the publishing entity should use the pubsub protocol (the following examples show use of the publish-subscribe subset specified in <cite>JEP-0163</cite>).</p>
<p>In order to provide information about one's location, the publishing entity should use the pubsub protocol (the following examples show use of the publish-subscribe subset specified in <cite>XEP-0163</cite>).</p>
<example caption='Entity publishes location'><![CDATA[
<iq type='set' from='portia@merchantofvenice.lit/pda'> id='publish1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -365,7 +365,7 @@
<li><p>The Wireless Village (now "IMPS") specifications for mobile instant messaging; these specifications define a presence attribute for address information as encapsulated in the IMPS "Address" element <note>The Wireless Village Initiative: Presence Attributes v1.1 (WV-029); for further information, visit &lt;<link url='http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html'>http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html</link>&gt;.</note>.</p></li>
<li><p>The SIP-based SIMPLE specifications; in particular, the IETF's GEOPRIV Working Group has defined an extension to the IETF's &pidf; for location information, as specified in &rfc4119; (also known as "PIDF-LO").</p></li>
</ol>
<p>The following table also maps the format defined herein to the vCard XML format specified in &jep0054;.</p>
<p>The following table also maps the format defined herein to the vCard XML format specified in &xep0054;.</p>
<table caption='Mapping XMPP Physical Location to IMPS, PIDF-LO, and vCard'>
<tr>
<th>XMPP</th>
@ -378,7 +378,7 @@
<td align='center'>&lt;Country/&gt;</td>
<td align='center'>&lt;country/&gt;</td>
<td align='center'>&lt;CTRY/&gt;
<note>As noted in JEP-0054, the XML vCard format defined in draft-dawson-vcard-xml-dtd-01 specified a &lt;COUNTRY/&gt; element rather than a &lt;CTRY/&gt; element; refer to JEP-0054 for details.</note>
<note>As noted in XEP-0054, the XML vCard format defined in draft-dawson-vcard-xml-dtd-01 specified a &lt;COUNTRY/&gt; element rather than a &lt;CTRY/&gt; element; refer to XEP-0054 for details.</note>
</td>
</tr>
<tr>
@ -442,7 +442,7 @@
<tr>
<td align='center'>--</td>
<td align='center'>&lt;Accuracy/&gt;
<note>This element provides accuracy in meters. The geolocation protocol defined in JEP-0080 specifies such an element for XMPP, which SHOULD be used when mapping from IMPS to XMPP.</note>
<note>This element provides accuracy in meters. The geolocation protocol defined in XEP-0080 specifies such an element for XMPP, which SHOULD be used when mapping from IMPS to XMPP.</note>
</td>
<td align='center'>--</td>
<td align='center'>--</td>
@ -467,10 +467,10 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/geoloc' to its registry of protocol namespaces.</p>
</section2>
@ -489,7 +489,7 @@
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0080: http://www.jabber.org/jeps/jep-0080.html
XEP-0080: http://www.xmpp.org/extensions/xep-0080.html
</xs:documentation>
</xs:annotation>
@ -521,4 +521,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

40
xep-0081.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber MIME Type</title>
<abstract>This JEP specifies a MIME type for launching a Jabber client as a helper application from most modern web browsers, and for completing basic use cases once the client is launched.</abstract>
<abstract>This document specifies a MIME type for launching a Jabber client as a helper application from most modern web browsers, and for completing basic use cases once the client is launched.</abstract>
&LEGALNOTICE;
<number>0081</number>
<status>Retracted</status>
@ -18,8 +18,8 @@
<spec>XMPP IM</spec>
<spec>RFC 2045</spec>
<spec>RFC 3023</spec>
<spec>JEP-0045</spec>
<spec>JEP-0077</spec>
<spec>XEP-0045</spec>
<spec>XEP-0077</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
@ -62,7 +62,7 @@
<p>Thankfully, it is not necessary for the large existing base of deployed software to support the xmpp: URI scheme in order to integrate Jabber/XMPP support. A well-accepted alternative approach
<note>See, for instance, &lt;<link url='http://www.mozilla.org/docs/web-developer/mimetypes.html'>http://www.mozilla.org/docs/web-developer/mimetypes.html</link>&gt; for information about MIME support in the Mozilla family of web browsers.</note>
is to define a MIME type (in accordance with &rfc2045;) and then reconfigure the relevant server and client software to correctly handle the new MIME type.</p>
<p>Therefore, this JEP defines a MIME type of "application/jabber+xml" (in particular, an XML media type in accordance with &rfc3023;). Files of this MIME type would commonly be accessed with a web browser via HTTP, although other access methods are possible (e.g., attachment of the MIME type to an email message). On opening a file of this type, a browser would (by configuration) invoke an appropriate "helper" application (i.e., an external Jabber client, plugin, or internal module) that would enable the user to interact with a Jabber/XMPP server. If the user is not currently connected to a server, the invoked program would be responsible for connecting the user with appropriate prompting for authentication credentials. The file passed to the helper application would define parameters needed to complete a certain use case, such as sending a message to another user.</p>
<p>Therefore, this document defines a MIME type of "application/jabber+xml" (in particular, an XML media type in accordance with &rfc3023;). Files of this MIME type would commonly be accessed with a web browser via HTTP, although other access methods are possible (e.g., attachment of the MIME type to an email message). On opening a file of this type, a browser would (by configuration) invoke an appropriate "helper" application (i.e., an external Jabber client, plugin, or internal module) that would enable the user to interact with a Jabber/XMPP server. If the user is not currently connected to a server, the invoked program would be responsible for connecting the user with appropriate prompting for authentication credentials. The file passed to the helper application would define parameters needed to complete a certain use case, such as sending a message to another user.</p>
<p>Note: The "application/jabber+xml" MIME type defined herein is not to be confused with the "application/xmpp+xml" MIME type defined in &rfc3923;; the two MIME types address different requirements and do not overlap or conflict.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
@ -77,8 +77,8 @@
<li>Join a groupchat room.</li>
<li>Register with a service.</li>
<!--
<li>Send a &jep0030; request.</li>
<li>Search a user directory (see &jep0055;).</li>
<li>Send a &xep0030; request.</li>
<li>Search a user directory (see &xep0055;).</li>
<li>Request another user's vCard.</li>
-->
</ul>
@ -118,7 +118,7 @@
<groupchat jid='jdev@conference.jabber.org'/>
</jabber>
]]></code>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for joining the conference room associated with the JID defined in the file. If the user completes the interface, the helper application shall then send a directed presence stanza to the JID (appending a room nickname to the JID as the resource identifier) as described in &jep0045;, first authenticating with the user's Jabber/XMPP server if necessary.</p>
<p>The browser passes this file to the helper application, which shall instantiate an appropriate interface for joining the conference room associated with the JID defined in the file. If the user completes the interface, the helper application shall then send a directed presence stanza to the JID (appending a room nickname to the JID as the resource identifier) as described in &xep0045;, first authenticating with the user's Jabber/XMPP server if necessary.</p>
</section2>
<section2 topic='Registering with a Service' anchor='register'>
<code><![CDATA[
@ -127,7 +127,7 @@
<register jid='headlines.shakespeare.lit'/>
</jabber>
]]></code>
<p>The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &jep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in <cite>JEP-0077</cite>.</p>
<p>The browser passes this file to the helper application, which shall send an IQ stanza of type='get' to the service associated with the JID defined in the file in order to determine the registration requirements (first authenticating with the user's Jabber/XMPP server if necessary), as described in &xep0077;. The helper application shall then instantiate an appropriate interface for registering with the service. If the user completes the interface, the helper application shall then send an IQ stanza of type='set' to the JID as described in <cite>XEP-0077</cite>.</p>
</section2>
<!--
<section2 topic='Making a Service Discovery Request' anchor='disco'>
@ -188,7 +188,7 @@
<p>When a helper application has finished processing a file of type "application/jabber+xml", it SHOULD discard the file; this helps to prevent security-related problems that may result from HTTP caching.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires registration of the "application/jabber+xml" content type with &IANA;. The registration is as follows:</p>
<p>This document requires registration of the "application/jabber+xml" content type with &IANA;. The registration is as follows:</p>
<code><![CDATA[
To: ietf-types@iana.org
@ -205,9 +205,9 @@ Encoding considerations: Same as encoding considerations of
of RFC 3920, the encoding must be UTF-8.
Security considerations: All of the security considerations
specified in RFC 3023 and RFC 3920 apply to this XML media
type. Refer to Section 11 of JSF JEP-0081.
type. Refer to Section 11 of JSF XEP-0081.
Interoperability considerations: (none)
Specification: JSF JEP-0081
Specification: JSF XEP-0081
Applications which use this media type: non-XMPP applications
(e.g., web browsers or email clients) that wish to invoke
XMPP-compliant applications for instant messaging and
@ -216,17 +216,17 @@ Additional information: This media type is not to be confused
with the "application/xmpp+xml" media type, which is for
use by native XMPP applications.
Person and email address to contact for further information:
Jabber Registrar, <registrar@jabber.org>
XMPP Registrar, <registrar@jabber.org>
Intended usage: COMMON
Author/Change controller: JSF, Jabber Registrar
Author/Change controller: JSF, XMPP Registrar
]]></code>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/mimetype' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='IANA Interaction' anchor='registrar-iana'>
<p>The Jabber Registrar shall interact with the IANA in order to register the media type defined herein.</p>
<p>The XMPP Registrar shall interact with the IANA in order to register the media type defined herein.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
@ -267,4 +267,4 @@ Author/Change controller: JSF, Jabber Registrar
<li>Add implementation notes for client handling on various platforms (e.g., DDE messages in Windows).</li>
</ol>
</section1>
</jep>
</xep>

34
xep-0082.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jabber Date and Time Profiles</title>
<abstract>This JEP specifies a standardization of ISO 8601 profiles and their lexical representation for use in Jabber/XMPP protocol extensions.</abstract>
<abstract>This document specifies a standardization of ISO 8601 profiles and their lexical representation for use in Jabber/XMPP protocol extensions.</abstract>
&LEGALNOTICE;
<number>0082</number>
<status>Active</status>
@ -66,7 +66,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>A number of Jabber protocols specify that dates and times should follow the format defined in &iso8601;. Unfortunately, ISO 8601 provides a great deal of flexibility with regard to the possible date and time "profiles" <note>The concept of an ISO 8601 profile is used in both RFC 3339 (<link url='http://www.ietf.org/rfc/rfc3339.txt'>http://www.ietf.org/rfc/rfc3339.txt</link>) and a W3C Note (<link url='http://www.w3.org/TR/NOTE-datetime'>http://www.w3.org/TR/NOTE-datetime</link>).</note> as well as their lexical representation. While that flexibility can lead to confusion, it is also true that the Jabber community has tended to use only a few restricted profiles of ISO 8601 dates and times (albeit with inconsistent lexical representations). This JEP formalizes those profiles and their lexical representation through reference to the datatypes defined in &w3xmlschema2;.</p>
<p>A number of Jabber protocols specify that dates and times should follow the format defined in &iso8601;. Unfortunately, ISO 8601 provides a great deal of flexibility with regard to the possible date and time "profiles" <note>The concept of an ISO 8601 profile is used in both RFC 3339 (<link url='http://www.ietf.org/rfc/rfc3339.txt'>http://www.ietf.org/rfc/rfc3339.txt</link>) and a W3C Note (<link url='http://www.w3.org/TR/NOTE-datetime'>http://www.w3.org/TR/NOTE-datetime</link>).</note> as well as their lexical representation. While that flexibility can lead to confusion, it is also true that the Jabber community has tended to use only a few restricted profiles of ISO 8601 dates and times (albeit with inconsistent lexical representations). This document formalizes those profiles and their lexical representation through reference to the datatypes defined in &w3xmlschema2;.</p>
</section1>
<section1 topic="Terminology">
<section2 topic='Time Terms'>
@ -95,7 +95,7 @@
<code>
CCYY-MM-DD
</code>
<p>This profile is equivalent to the 'date' datatype defined in XML Schema <note>The 'date' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#date'>http://www.w3.org/TR/xmlschema-2/#date</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'date'. If there are differences between the description in this JEP and those in XML Schema, the latter overrule.</p>
<p>This profile is equivalent to the 'date' datatype defined in XML Schema <note>The 'date' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#date'>http://www.w3.org/TR/xmlschema-2/#date</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'date'. If there are differences between the description in this document and those in XML Schema, the latter overrule.</p>
<example caption='The date of American independence'>
1776-07-04
</example>
@ -106,7 +106,7 @@
CCYY-MM-DDThh:mm:ss[.sss]TZD
</code>
<p>The Time Zone Definition is mandatory and MUST be either UTC (denoted by addition of the character 'Z' to the end of the string) or some offset from UTC (denoted by addition of '[+|-]' and 'hh:mm' to the end of the string). The fractions of a second are optional and MAY be ignored if included (although a Jabber protocol using the DateTime profile MAY require the fractions of a second).</p>
<p>This profile is equivalent to the 'dateTime' datatype defined in XML Schema <note>The 'dateTime' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#dateTime'>http://www.w3.org/TR/xmlschema-2/#dateTime</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'dateTime'. If there are differences between the description in this JEP and those in XML Schema, the latter overrule.</p>
<p>This profile is equivalent to the 'dateTime' datatype defined in XML Schema <note>The 'dateTime' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#dateTime'>http://www.w3.org/TR/xmlschema-2/#dateTime</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'dateTime'. If there are differences between the description in this document and those in XML Schema, the latter overrule.</p>
<example caption='Datetime of the first human steps on the Moon (UTC)'>
1969-07-21T02:56:15Z
</example>
@ -120,20 +120,20 @@
hh:mm:ss[.sss][TZD]
</code>
<p>The Time Zone Definition is optional; if included, it MUST be either UTC (denoted by addition of the character 'Z' to the end of the string) or some offset from UTC (denoted by addition of '[+|-]' and 'hh:mm' to the end of the string). The fractions of a second are optional and MAY be ignored if included (although a Jabber protocol using the DateTime profile MAY require the fractions of a second).</p>
<p>This profile is equivalent to the 'time' datatype defined in XML Schema <note>The 'time' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#time'>http://www.w3.org/TR/xmlschema-2/#time</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'time'. If there are differences between the description in this JEP and those in XML Schema, the latter overrule.</p>
<p>This profile is equivalent to the 'time' datatype defined in XML Schema <note>The 'time' datatype is defined at &lt;<link url='http://www.w3.org/TR/xmlschema-2/#time'>http://www.w3.org/TR/xmlschema-2/#time</link>&gt;.</note>. When an XML schema is used to define a Jabber protocol that uses this profile, the datatype MUST be an XML Schema 'time'. If there are differences between the description in this document and those in XML Schema, the latter overrule.</p>
<example caption='Time for tea'>
16:00:00
</example>
</section2>
</section1>
<section1 topic='Migration'>
<p>Some existing Jabber protocols use a different lexical representation for datetimes than the representation defined in XML Schema and specified by this JEP. These are &jep0090;, &jep0091;, and &jep0009;. (The representation of dates in &jep0054; matches that specified herein.) These older protocols represent datetimes as follows:</p>
<p>Some existing Jabber protocols use a different lexical representation for datetimes than the representation defined in XML Schema and specified by this document. These are &xep0090;, &xep0091;, and &xep0009;. (The representation of dates in &xep0054; matches that specified herein.) These older protocols represent datetimes as follows:</p>
<code>
CCYYMMDDThh:mm:ss
</code>
<p>The primary standard notation recommended by ISO 8601 includes the separators ("-" for dates and ":" for times), although ISO 8601 allows omission of the separators for applications in which compactness is more important than human readability. It is arguable whether Jabber applications using 'jabber:iq:time' and 'jabber:x:delay' require such compactness, but these protocols are in wide use today and have been implemented using the format shown above. Therefore, applications receiving data in those namespaces SHOULD be liberal in what they accept by handling datetimes either in the "CCYYMMDDThh:mm:ss" format or in the lexical representation defined in XML Schema and specified by this JEP. Applications generating data in those namespaces SHOULD use the existing format ("CCYYMMDDThh:mm:ss"), and are effectively "grandfathered" with respect to the date and time formats defined herein. While eventually it would be good to deprecate the older datetime representation for these protocols, the schedule for such deprecation (if any) shall be specified in official JEPs for these older protocols.</p>
<p>Jabber-RPC is a special case, since the specification for &xmlrpc; includes only one example for datetimes, which is of the format "CCYYMMDDThh:mm:ss". Apparently many implementations of XML-RPC have taken this lexical representation as canonical, and do not support any other representation; because Jabber-RPC normally provides an interface to software that is outside the Jabber network, it is prudent for Jabber-RPC implementations to generate dates in the format shown in the XML-RPC specification, not that defined in this JEP.</p>
<p>New protocols approved by the Jabber Software Foundation MUST use the lexical representations defined in this JEP.</p>
<p>The primary standard notation recommended by ISO 8601 includes the separators ("-" for dates and ":" for times), although ISO 8601 allows omission of the separators for applications in which compactness is more important than human readability. It is arguable whether Jabber applications using 'jabber:iq:time' and 'jabber:x:delay' require such compactness, but these protocols are in wide use today and have been implemented using the format shown above. Therefore, applications receiving data in those namespaces SHOULD be liberal in what they accept by handling datetimes either in the "CCYYMMDDThh:mm:ss" format or in the lexical representation defined in XML Schema and specified by this document. Applications generating data in those namespaces SHOULD use the existing format ("CCYYMMDDThh:mm:ss"), and are effectively "grandfathered" with respect to the date and time formats defined herein. While eventually it would be good to deprecate the older datetime representation for these protocols, the schedule for such deprecation (if any) shall be specified in official XEPs for these older protocols.</p>
<p>Jabber-RPC is a special case, since the specification for &xmlrpc; includes only one example for datetimes, which is of the format "CCYYMMDDThh:mm:ss". Apparently many implementations of XML-RPC have taken this lexical representation as canonical, and do not support any other representation; because Jabber-RPC normally provides an interface to software that is outside the Jabber network, it is prudent for Jabber-RPC implementations to generate dates in the format shown in the XML-RPC specification, not that defined in this document.</p>
<p>New protocols approved by the Jabber Software Foundation MUST use the lexical representations defined in this document.</p>
</section1>
<section1 topic='Implementation Notes'>
<p>The 'date', 'dateTime', and 'time' datatypes defined in XML Schema address several "edge cases" such as dates before the year 0000 and after the year 9999, as well as odd timezones no longer in use; most Jabber applications can safely ignore these edge cases, since it is highly unlikely that a Jabber entity will generate such representations.</p>
@ -142,9 +142,9 @@
<p>There are no security features or concerns related to this proposal.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<p>This JEP requires no interaction with the &REGISTRAR;.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</jep>
</xep>

28
xep-0083.xml
View File

@ -1,13 +1,13 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Nested Roster Groups</title>
<abstract>This JEP defines a protocol extension that enables nested sub-groups to exist within the Jabber roster, while retaining backwards compatibility and ensuring that the roster remains usable by all clients.</abstract>
<abstract>This document defines an XMPP protocol extension that enables nested sub-groups to exist within the Jabber roster, while retaining backwards compatibility and ensuring that the roster remains usable by all clients.</abstract>
&LEGALNOTICE;
<number>0083</number>
<status>Active</status>
@ -16,13 +16,13 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0049</spec>
<spec>XEP-0049</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>nestedgroups</shortname>
<schemaloc>
<url>http://jabber.org/protocol/nestedgroups/delimiter.xsd</url>
<url>http://www.xmpp.org/schemas/delimiter.xsd</url>
</schemaloc>
<author>
<firstname>Rachel</firstname>
@ -44,10 +44,10 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>In many modern instant messaging clients, client authors implement a way to nest contact groups within other contact groups. Usually this is implemented on the client side, since many instant messaging networks do not support nesting contact groups in this manner. The limitation of this system is that if the user changes from one client to another, or even a second installation of the same client, the user loses all of his or her sub-group information. This JEP aims to solve that problem within Jabber, by providing for a way to store sub-groups on the Jabber roster without breaking existing clients.</p>
<p>In many modern instant messaging clients, client authors implement a way to nest contact groups within other contact groups. Usually this is implemented on the client side, since many instant messaging networks do not support nesting contact groups in this manner. The limitation of this system is that if the user changes from one client to another, or even a second installation of the same client, the user loses all of his or her sub-group information. This document aims to solve that problem within Jabber, by providing for a way to store sub-groups on the Jabber roster without breaking existing clients.</p>
</section1>
<section1 topic='roster:delimiter Namespace' anchor='namespace'>
<p>Jabber already provides a useful method for storing client data on the server using &jep0049;. All we need to do is create a new roster element and a namespace to store the delimiter for nested groups, roster:delimiter. This element MUST contain XML character data that defines a string to be used as a delimiter in the roster groups. <note>If the element does not contain XML character data, a compliant client SHOULD assume that nested groups are disabled for the user's account.</note></p>
<p>Jabber already provides a useful method for storing client data on the server using &xep0049;. All we need to do is create a new roster element and a namespace to store the delimiter for nested groups, roster:delimiter. This element MUST contain XML character data that defines a string to be used as a delimiter in the roster groups. <note>If the element does not contain XML character data, a compliant client SHOULD assume that nested groups are disabled for the user's account.</note></p>
<p>A single-character roster delimiter (e.g., "/") would make client implementation easier, but be more limiting to the end-user in terms of choices for naming roster groups, so a string is ideal. Therefore, the delimiter SHOULD contain multiple characters in order to avoid inconveniencing the user, but single-character delimiters MUST be honored by the client. The exception is if the delimiter is a single alphanumeric character (a-z, A-Z, 0-9); in this case compliant clients MUST treat the situation as if nesting were disabled, to avoid malicious use of this element by setting 'e' or 'm' or some other common single character as a delimiter.</p>
<p>A compliant client SHOULD ask for the nested delimiter before requesting the user's roster, in order to know whether or not to parse the roster 'group' fields accordingly. If there is no delimiter stored, a client MAY set a delimiter but MUST either prompt the user for a delimiter, or use a user-configurable default.</p>
</section1>
@ -122,12 +122,12 @@ SERVER:
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>There are no security features or concerns related to this proposal above and beyond those specified for roster management in &xmppim; and for private XML storage in JEP-0049.</p>
<p>There are no security features or concerns related to this proposal above and beyond those specified for roster management in &xmppim; and for private XML storage in XEP-0049.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'roster:delimiter' in its registry of protocol namespaces.</p>
</section2>
@ -144,11 +144,11 @@ SERVER:
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0083: http://www.jabber.org/jeps/jep-0083.html
XEP-0083: http://www.xmpp.org/extensions/xep-0083.html
</xs:documentation>
</xs:annotation>
<xs:element name='roster' type='xs:string'/>
]]></code>
</section1>
</jep>
</xep>

36
xep-0084.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>User Avatar</title>
<abstract>This document defines an XMPP protocol extension for exchanging user avatars.</abstract>
@ -15,12 +15,12 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0030</spec>
<spec>JEP-0060</spec>
<spec>JEP-0163</spec>
<spec>XEP-0030</spec>
<spec>XEP-0060</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes>
<spec>JEP-0008</spec>
<spec>XEP-0008</spec>
</supersedes>
<supersededby/>
<shortname>avatar</shortname>
@ -78,7 +78,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Many communication applications allow for the association of a small image or icon with a user of that application. Usually, such an "avatar" is not intended to be an accurate picture of the user's actual physical appearance, but rather a representation (often fanciful) of the user's desired self-image or a transient state of the user (such as a mood or activity). This document outlines a way to incorporate avatars into current Jabber/XMPP systems by layering this functionality on top of the XMPP &jep0060; extension ("pubsub"), specifically the &jep0163; subset ("PEP"), which is designed for use in the context of XMPP instant messaging and presence systems that conform to &rfc3921;.</p>
<p>Many communication applications allow for the association of a small image or icon with a user of that application. Usually, such an "avatar" is not intended to be an accurate picture of the user's actual physical appearance, but rather a representation (often fanciful) of the user's desired self-image or a transient state of the user (such as a mood or activity). This document outlines a way to incorporate avatars into current Jabber/XMPP systems by layering this functionality on top of the XMPP &xep0060; extension ("pubsub"), specifically the &xep0163; subset ("PEP"), which is designed for use in the context of XMPP instant messaging and presence systems that conform to &rfc3921;.</p>
<p>The protocol defined herein uses two pubsub nodes: one node for "metadata" about the avatar state (called the "metadata node") and one for the avatar data itself (called the "data node"). This separation of metadata from data conserves bandwidth and enables both the publisher and the subscriber to cache the avatar data. (For example, a user might toggle between two or three avatars, in which case the user's contacts can display a locally cached version of the images without having to retrieve or receive the full image each time.)</p>
<p>This protocol also allows storage of avatar data at a URL accessible via HTTP (see &rfc2616;). <note>By "accessible via HTTP" is meant that the data is available at an http: or https: URI.</note> This can be helpful as a fallback mechanism if a pubsub-aware data repository is not available. It also makes it possible for avatar images to be hosted on public websites (e.g., an end-user-oriented community site) and retrieved from that site rather than handled directly by the publishing client in any fashion.</p>
<p>Finally, this protocol also enables XMPP applications to optionally integrate with third-party services that host user avatars (e.g., online gaming systems and virtual worlds).</p>
@ -110,7 +110,7 @@
<li>Optionally, user disables avatar display.</li>
</ol>
<p>This process flow is described more fully in the following sections.</p>
<p>Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in <cite>JEP-0163</cite>.</p>
<p>Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in <cite>XEP-0163</cite>.</p>
<section2 topic='User Creates Metadata Node' anchor='process-createmeta'>
<p>In order to publish notifications related to its avatar, the user MUST first create a node for his or her avatar metadata:</p>
<example caption='Pubsub metadata node creation request'><![CDATA[
@ -130,7 +130,7 @@
</pubsub>
</iq>
]]></example>
<p>The NodeID MUST be "http://jabber.org/protocol/avatar#metadata" and the access model SHOULD be "presence". Note: If the default access model (see <cite>JEP-0163</cite>) is the same as the desired access model, the user can send an empty &lt;configure/&gt; element rather than including a data form as shown above.</p>
<p>The NodeID MUST be "http://jabber.org/protocol/avatar#metadata" and the access model SHOULD be "presence". Note: If the default access model (see <cite>XEP-0163</cite>) is the same as the desired access model, the user can send an empty &lt;configure/&gt; element rather than including a data form as shown above.</p>
<example caption='Pubsub service replies with success'><![CDATA[
<iq type='result' to='juliet@capulet.com/chamber' id='create1'/>
]]></example>
@ -213,7 +213,7 @@
</addresses>
</message>
]]></example>
<p>Note the inclusion of &jep0033; information about the publishing resource (see <cite>JEP-0163</cite> and <cite>JEP-0060</cite> for details).</p>
<p>Note the inclusion of &xep0033; information about the publishing resource (see <cite>XEP-0163</cite> and <cite>XEP-0060</cite> for details).</p>
</section2>
<section2 topic='Subscribers Retrieve Data' anchor='process-subretrieve'>
<p>Upon receiving the notification, each subscriber SHOULD determine if it has a locally cached copy of that avatar (which it can determine by searching for an image identified by the ItemID). If the subscriber already has a locally cached copy of the avatar image, it MUST NOT retrieve the image data.</p>
@ -431,7 +431,7 @@
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<section2 topic='Discovering Avatar Availability' anchor='disco-sub'>
<p>A contact can determine if another user publishes avatars using this protocol by sending a &jep0030; items ("disco#items") request to the user's bare JID (&BAREJID;):</p>
<p>A contact can determine if another user publishes avatars using this protocol by sending a &xep0030; items ("disco#items") request to the user's bare JID (&BAREJID;):</p>
<example caption='Disco items request'><![CDATA[
<iq type='get'
from='romeo@montague.net/orchard'
@ -452,7 +452,7 @@
</query>
</iq>
]]></example>
<p>The contact then MAY subscribe to the metadata node following the protocol specified in <cite>JEP-0060</cite>. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above).</p>
<p>The contact then MAY subscribe to the metadata node following the protocol specified in <cite>XEP-0060</cite>. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above).</p>
</section2>
</section1>
<section1 topic='Business Rules' anchor='bizrules'>
@ -465,12 +465,12 @@
<p>If a user has multiple online resources at the same time, each resource MAY publish a different avatar. A user SHOULD subscribe to his or her own metadata in order to know the avatars that are being published to all resources. The PEP service SHOULD include the replyto address of the publishing resource as shown above in order to facilitate differentiation between per-resource avatars.</p>
</section2>
<section2 topic='Avatar Synchronization' anchor='impl-sync'>
<p>When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar using the "get-items" method described in <cite>JEP-0060</cite>.</p>
<p>When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar using the "get-items" method described in <cite>XEP-0060</cite>.</p>
</section2>
<section2 topic='Image Handling' anchor='impl-images'>
<p>It is the responsibility of the receiving application to determine which avatar format to retrieve (e.g., "image/gif" rather than "image/png") and to determine the appropriate method for retrieval (e.g., HTTP rather than pubsub).</p>
<p>The receiving application SHOULD NOT scale up an image when displaying it.</p>
<p>If an avatar is not available for a contact, the receiving MAY display the contact's photo, e.g., as provided in the contact's vCard (see &jep0054;) or other profile information.</p>
<p>If an avatar is not available for a contact, the receiving MAY display the contact's photo, e.g., as provided in the contact's vCard (see &xep0054;) or other profile information.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -479,7 +479,7 @@
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document makes use of IANA-registered content types, but requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; shall include 'http://jabber.org/protocol/avatar#data' and 'http://jabber.org/protocol/avatar#metadata' in its registry of protocol namespaces.</p>
</section2>
@ -558,4 +558,4 @@
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006. The remaining authors are thankful for his work on this specification.</p>
</section1>
</jep>
</xep>

40
xep-0085.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Chat State Notifications</title>
<abstract>This document defines an XMPP protocol extension for communicating the status of a user in a chat session.</abstract>
@ -16,13 +16,13 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>JEP-0030</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>chatstates</shortname>
<schemaloc>
<url>http://jabber.org/protocol/chatstates/chatstates.xsd</url>
<url>http://www.xmpp.org/schemas/chatstates.xsd</url>
</schemaloc>
&stpeter;
&dizzyd;
@ -48,7 +48,7 @@
<version>0.14</version>
<date>2005-07-20</date>
<initials>psa</initials>
<remark><p>Clarified terminology; specified suggested state changes; removed section on superseding JEP-0022.</p></remark>
<remark><p>Clarified terminology; specified suggested state changes; removed section on superseding XEP-0022.</p></remark>
</revision>
<revision>
<version>0.13</version>
@ -60,7 +60,7 @@
<version>0.12</version>
<date>2005-07-15</date>
<initials>psa</initials>
<remark><p>Clarified business rules regarding generation of notifications; added reference to JEP-0155; rewrote introduction; moved previous introductory text to section on superseding JEP-0022.</p></remark>
<remark><p>Clarified business rules regarding generation of notifications; added reference to XEP-0155; rewrote introduction; moved previous introductory text to section on superseding XEP-0022.</p></remark>
</revision>
<revision>
<version>0.11</version>
@ -130,14 +130,14 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Many instant messaging systems include notifications about the state of one's conversation partner in a one-to-one chat (or, sometimes, in a many-to-many chat). Usually these are limited to notification that one's partner is currently typing -- e.g., the Composing event in <cite>JEP-0022</cite> (see &jep0022;). However, a composing event is essentially information about a person's participation in or involvement with the chat "session" and therefore is really a session-level state rather than a per-message event -- e.g., the Delivered and Displayed events in <cite>JEP-0022</cite>. While the composing event is interesting, the concept of a session-level state can be extended to answer a variety of questions about the participation of a person in a real-time chat conversation, such as:</p>
<p>Many instant messaging systems include notifications about the state of one's conversation partner in a one-to-one chat (or, sometimes, in a many-to-many chat). Usually these are limited to notification that one's partner is currently typing -- e.g., the Composing event in <cite>XEP-0022</cite> (see &xep0022;). However, a composing event is essentially information about a person's participation in or involvement with the chat "session" and therefore is really a session-level state rather than a per-message event -- e.g., the Delivered and Displayed events in <cite>XEP-0022</cite>. While the composing event is interesting, the concept of a session-level state can be extended to answer a variety of questions about the participation of a person in a real-time chat conversation, such as:</p>
<ul>
<li>Has this person paused the composition?</li>
<li>Is this person actively paying attention to the chat?</li>
<li>Is this person temporarily inactive (i.e., not paying attention right now)?</li>
<li>Is this person simply gone (i.e., no longer participating in the chat)?</li>
</ul>
<p>To answer such questions, this JEP supplements the traditional composing state by defining four additional chat states (paused, active, inactive, gone), for a total of five states that (it is hoped) together fully describe the possible states of a person's participation in or involvement with a chat conversation. <note>These states do not necessarily refer to the state of the client interface and certainly not to the disposition of a particular message. However, the user's involvement with the system, device, chat interface, or input interface can provide important clues regarding the user's involvement with the chat session, which should be used by the client in determining when to generate chat state notifications.</note></p>
<p>To answer such questions, this document supplements the traditional composing state by defining four additional chat states (paused, active, inactive, gone), for a total of five states that (it is hoped) together fully describe the possible states of a person's participation in or involvement with a chat conversation. <note>These states do not necessarily refer to the state of the client interface and certainly not to the disposition of a particular message. However, the user's involvement with the system, device, chat interface, or input interface can provide important clues regarding the user's involvement with the chat session, which should be used by the client in determining when to generate chat state notifications.</note></p>
</section1>
<section1 topic='Definitions' anchor='definitions'>
<p>In essence, chat state notifications can be thought of as a form of chat-specific presence. For example, consider what might happen if a user "loses" a chat window on his desktop; the user might still be interacting with his messaging client (thus never automatically changing his basic presence to "away"), but the user's state with regard to the chat session might change progressively from active to inactive to gone. This information would help the user's conversation partner understand why she has not received a response to her messages in the chat session.</p>
@ -201,7 +201,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
<p>Note: All four of the states shown may transition to the GONE state.</p>
</section1>
<section1 topic='Discovering Support' anchor='disco'>
<p>If an entity supports the Chat State Notifications protocol, it MUST advertise that fact in its responses to &jep0030; information ("diso#info") requests by returning a feature of "http://jabber.org/protocol/chatstates":</p>
<p>If an entity supports the Chat State Notifications protocol, it MUST advertise that fact in its responses to &xep0030; information ("diso#info") requests by returning a feature of "http://jabber.org/protocol/chatstates":</p>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
from='romeo@shakespeare.lit/orchard'
@ -222,11 +222,11 @@ INACTIVE <--> ACTIVE <--> COMPOSING
</query>
</iq>
]]></example>
<p>In addition, support for the Chat States Notification protocol can be determined through the dynamic profile of Service Discovery defined in &jep0115;.</p>
<p>In addition, support for the Chat States Notification protocol can be determined through the dynamic profile of Service Discovery defined in &xep0115;.</p>
</section1>
<section1 topic='Business Rules' anchor='bizrules'>
<section2 topic='Generation of Notifications' anchor='bizrules-gen'>
<p>Before generating chat state notifications, a User SHOULD explicitly discover whether the Contact supports the protocol defined herein (as described in the <link url='#disco'>Discovering Support</link> section of this document) or explicitly negotiate the use of chat state notifications with the Contact (via &jep0155;).</p>
<p>Before generating chat state notifications, a User SHOULD explicitly discover whether the Contact supports the protocol defined herein (as described in the <link url='#disco'>Discovering Support</link> section of this document) or explicitly negotiate the use of chat state notifications with the Contact (via &xep0155;).</p>
<p>In the absence of explicit discovery or negotiation, the User MAY implicitly request and discover the use of chat state notifications in a one-to-one chat session by adhering to the following business rules:</p>
<ol start='1'>
<li>If the User desires chat state notifications, the initial content message sent to the Contact MUST contain a chat state notification extension, which SHOULD be &lt;active/&gt;.</li>
@ -264,7 +264,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
</tr>
</table>
<p>A client MUST allow the user to configure whether he or she wants to send chat state notifications.</p>
<p>Note: Support for only &lt;active/&gt; and &lt;composing/&gt; is functionally equivalent to supporting the Composing event from <cite>JEP-0022</cite>.</p>
<p>Note: Support for only &lt;active/&gt; and &lt;composing/&gt; is functionally equivalent to supporting the Composing event from <cite>XEP-0022</cite>.</p>
</section2>
<section2 topic='Repetition' anchor='bizrules-rep'>
<p>Even if the user types continuously for a long time (e.g., while composing a lengthy reply), the client MUST NOT send more than one standalone &lt;composing/&gt; notification in a row. More generally, a client MUST NOT send a second instance of any given standalone notification (i.e., a standalone notification MUST be followed by a different state, not repetition of the same state). However, every content message SHOULD contain an &lt;active/&gt; notification.</p>
@ -278,7 +278,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
</ol>
</section2>
<section2 topic='Use in Groupchat' anchor='bizrules-groupchat'>
<p>Chat state notifications MAY be sent in the context of groupchat rooms (e.g., as defined in &jep0045;). The following business rules apply:</p>
<p>Chat state notifications MAY be sent in the context of groupchat rooms (e.g., as defined in &xep0045;). The following business rules apply:</p>
<ol>
<li>A client MAY send chat state notifications even if not all room occupants do so.</li>
<li>A client SHOULD NOT generate &lt;gone/&gt; notifications.</li>
@ -302,7 +302,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
</ol>
</section2>
<section2 topic='Server Handling of Notifications' anchor='bizrules-notify'>
<p>Servers in constrained network environments (e.g., serving small-footprint clients via &jep0025; or &jep0124;) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to <cite>JEP-0022</cite>, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service.</p>
<p>Servers in constrained network environments (e.g., serving small-footprint clients via &xep0025; or &xep0124;) and services that rebroadcast message stanzas (e.g., Multi-User Chat services) MAY process standalone notifications differently from other messages. In particular, a server or service MAY refuse to deliver standalone notifications to its users, and SHOULD NOT store them offline. In contrast to <cite>XEP-0022</cite>, chat state notifications are completely the responsibility of the client, and MUST NOT be generated by a server or service.</p>
</section2>
</section1>
<section1 topic='A Simple Example' anchor='example-basic'>
@ -512,9 +512,9 @@ INACTIVE <--> ACTIVE <--> COMPOSING
<p>The states of a chat thread may reveal information about a user's interaction with his or her computer, including his or her physical presence; such information SHOULD NOT be revealed to conversation partners who are not trusted to know such information. Client implementations MUST provide a mechanism that enables the user to disable chat state notifications if desired.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This JEP requires no interaction with &IANA;.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/chatstates' in its registry of protocol namespaces.</p>
</section2>
@ -532,7 +532,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0085: http://www.jabber.org/jeps/jep-0085.html
XEP-0085: http://www.xmpp.org/extensions/xep-0085.html
</xs:documentation>
</xs:annotation>
@ -551,4 +551,4 @@ INACTIVE <--> ACTIVE <--> COMPOSING
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

10
xep-0086.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM '../jep.ent'>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Error Condition Mappings</title>
<abstract>A mapping to enable legacy entities to correctly handle errors from XMPP-aware entities.</abstract>
@ -344,4 +344,4 @@
<section1 topic='Conclusion'>
<p>Mapping legacy error codes to XMPP-style errors is an inexact science, and there are likely to be inconsistencies in some places. However, it is the authors' belief that the mapping presented in this document will be adequate for the majority of cases, and will help smooth the migration to XMPP-compliant implementations.</p>
</section1>
</jep>
</xep>

34
xep-0087.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Stream Initiation</title>
<abstract>A common method to initiate a stream with meta information</abstract>
@ -13,9 +13,9 @@
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>JEP-0030</dependencies>
<dependencies>XEP-0030</dependencies>
<supersedes>None</supersedes>
<supersededby>JEP-0095</supersededby>
<supersededby>XEP-0095</supersededby>
<shortname>si</shortname>
<author>
<firstname>Thomas</firstname>
@ -33,7 +33,7 @@
<section1 topic='Introduction'>
<p>
As more people begin to make use of streams in Jabber, there becomes a need
for more descriptive negotiation of which stream to use. This JEP provides
for more descriptive negotiation of which stream to use. This document provides
a method to negotiate a stream and provide some meta-information about the
streams usage.
</p>
@ -91,7 +91,7 @@
<p>
Before a Stream Initiation is attempted the Sender should be sure that the
Receiver supports both Stream Initiation and the specific profile that they
wish to use. This is discovered by using &jep0030;:
wish to use. This is discovered by using &xep0030;:
</p>
<example caption='Requesting Disco Information From Receiver'>
<![CDATA[
@ -106,7 +106,7 @@
</example>
<p>
The Receiver will advertise the "http://jabber.org/protocol/si" namespace as
a feature to represent they implement this JEP. The specific profiles can
a feature to represent they implement this document. The specific profiles can
be found by looking for
"http://jabber.org/protocol/si/profile/profile-name". Shown in the result
is a potential file transfer profile:
@ -302,16 +302,16 @@
&lt;si&gt; profile attribute. Next, the information for the headers is
decided upon. Each piece of information will be transported in a
&lt;header&gt; tag. The name attribute is a descriptive key that can be
looked up at the Jabber Registrar or JEP describing the profile. The
looked up at the XMPP Registrar or XEP describing the profile. The
actual data in the &lt;header&gt; is the fact related to the name
attribute. It must also be stated whether the header is required or
optional.
</p>
<p>
This JEP does not define any profiles, nor does it place any restrictions
on what type of information a profile should detail. This JEP also does
This document does not define any profiles, nor does it place any restrictions
on what type of information a profile should detail. This document also does
not place restrictions on what may be placed in a &lt;header&gt;. Other
JEPs will define profiles to be used with Stream Initiation.
XEPs will define profiles to be used with Stream Initiation.
</p>
</section2>
<section2 topic='Stream Interaction'>
@ -320,7 +320,7 @@
provide many benefits. In order to fully appreciate these benefits,
streams must link the Stream Initiation to the stream. The id
attribute of the &lt;si&gt; node is intended to provide this link. It is
out of scope of this JEP to define how streams will make use of this
out of scope of this document to define how streams will make use of this
facility, but it does suggest some methods:
<ul>
<li>
@ -407,11 +407,11 @@
</section1>
<section1 topic='IANA Considerations'>
<p>
This JEP uses the MIME types as recorded by IANA, but no other direct
This document uses the MIME types as recorded by IANA, but no other direct
interaction is necessary.
</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>
The "http://jabber.org/protocol/si" namespace will be registered.
The registrar will track header profiles for different stream initiation
@ -426,4 +426,4 @@
<p>To follow.</p>
</section2>
</section1>
</jep>
</xep>

30
xep-0088.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Client Webtabs</title>
<abstract>A protocol for displaying web-based tabs in clients.</abstract>
@ -15,8 +15,8 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0030</spec>
<spec>JEP-0049</spec>
<spec>XEP-0030</spec>
<spec>XEP-0049</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -37,7 +37,7 @@
<version>0.3</version>
<date>2003-09-30</date>
<initials>red</initials>
<remark>Moved service discovery to top of use cases, added option for separate webtab provider and added reference to JEP-0101.</remark>
<remark>Moved service discovery to top of use cases, added option for separate webtab provider and added reference to XEP-0101.</remark>
</revision>
<revision>
<version>0.2</version>
@ -56,7 +56,7 @@
<p>Webtabs are a way for servers to specify a number to web pages which can be used in clients and displayed like the web-based services in Yahoo Messenger, MSN Messenger and JIM. This enables a server administrator to easily create services for Jabber clients and also help to integrate Jabber clients with existing web-based applications.</p>
</section1>
<section1 topic='Requirements'>
<p>The motivations for this JEP are:</p>
<p>The motivations for this document are:</p>
<ul>
<li>To enable servers to specify a selection of web-based services for use in a client.</li>
<li>To allow easy integration with existing web-based systems.</li>
@ -66,7 +66,7 @@
</section1>
<section1 topic='Use Cases'>
<section2 topic='Service Discovery'>
<p>&jep0030; SHALL be used for discovering support for webtabs on servers.</p>
<p>&xep0030; SHALL be used for discovering support for webtabs on servers.</p>
<example caption='Disco info response containing support for webtabs'><![CDATA[
<iq
type='result'
@ -132,12 +132,12 @@
</query>
</iq>]]></example>
<p>The webtab contains CDATA which is the URL of the webtab, the webtab is an HTML page retrieved from an HTTP server using a standard browser which you embed into your client UI using a technique such as the IWebBrowser2 control interface on windows which allows you to embed either the IE or Gecko engines depending on what you have installed, this data is REQUIRED.</p>
<p>The "type" attribute tells the client what the service being provided is, this allows a client to display icons on the tabs to represent them, handling of the type in clients is OPTIONAL, inclusion of this attribute is REQUIRED (See "Jabber Registrar Considerations" for examples of values for this attribute).</p>
<p>The "type" attribute tells the client what the service being provided is, this allows a client to display icons on the tabs to represent them, handling of the type in clients is OPTIONAL, inclusion of this attribute is REQUIRED (See "XMPP Registrar Considerations" for examples of values for this attribute).</p>
<p>The "name" attribute is the offical name of a particular service this can be displayed as the tab name, this attribute is REQUIRED.</p>
<p>The "id" attribute is a unique identifier for a service which you can use to refer to it later, used for when using private storage to store a preference to which tabs should be visible, this attribute is REQUIRED.</p>
</section2>
<section2 topic='Private storage of preferences'>
<p>&jep0049; SHALL be used for storing webtab preferences.</p>
<p>&xep0049; SHALL be used for storing webtab preferences.</p>
<example caption='Request for current webtab preferences'><![CDATA[
<iq
to='domain.com'
@ -165,7 +165,7 @@
<p>The "visible" attribute tells the client that a tab SHOULD or SHOULD NOT be hidden, a client SHOULD provide an interface for managing the visibility of the tabs and updating the preferences appropriately, this attribute is REQUIRED.</p>
</section2>
<section2 topic='Service authentication'>
<p>It is RECOMMENDED that a mechanism such as &jep0101; be used for automatic service authentication.</p>
<p>It is RECOMMENDED that a mechanism such as &xep0101; be used for automatic service authentication.</p>
</section2>
</section1>
@ -178,12 +178,12 @@
</ul>
</section1>
<section1 topic='Security Considerations'>
<p>It is recommended that JEP-0101 be used to provide transparent authentication of the webtabs.</p>
<p>It is recommended that XEP-0101 be used to provide transparent authentication of the webtabs.</p>
</section1>
<section1 topic='IANA Considerations'>
<p>No IANA interaction required.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; will need to register the new namespace of "http://jabber.org/protocol/webtab" and possibly the list of offical types will need to be managed too.</p>
<table caption='Possible types for webtabs'>
<tr>
@ -212,4 +212,4 @@
</tr>
</table>
</section1>
</jep>
</xep>

16
xep-0089.xml
View File

@ -1,10 +1,10 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd' [
<!ENTITY % ents SYSTEM "../jep.ent">
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>
<jep>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Generic Alerts</title>
<abstract>A protocol for generic alerts (similar to .NET Alerts service).</abstract>
@ -17,7 +17,7 @@
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>Not yet assigned</shortname>
<!-- firstname, surname, email, and jid are all MANDATORY per JEP-0001 -->
<!-- firstname, surname, email, and jid are all MANDATORY per XEP-0001 -->
<!-- include one author section for each co-author -->
<author>
<firstname>Richard</firstname>
@ -42,7 +42,7 @@
<p>Generic Alerts is a way to extend headlines to allow functionality similar to .NET Alerts.</p>
</section1>
<section1 topic='Requirements'>
<p>The motivations for this JEP are:</p>
<p>The motivations for this document are:</p>
<ul>
<li>To allow services to send alerts to users, e.g. like an auction notifying you when you are outbid or that you have won</li>
</ul>
@ -76,7 +76,7 @@
<section1 topic='IANA Considerations'>
<p>No IANA interaction required.</p>
</section1>
<section1 topic='Jabber Registrar Considerations'>
<section1 topic='XMPP Registrar Considerations'>
<p>The &REGISTRAR; will need to register the new namespace of "http://jabber.org/protocol/alert".</p>
</section1>
</jep>
</xep>