moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

JEP to XEP

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@43 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-04 16:37:57 +00:00
parent a76c0f0930
commit 8eeba9ccd3
10 changed files with 159 additions and 159 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
xep-0120.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>Infobits</title>
<abstract>NOTE: This proposal was retracted by the author on 2004-02-19.</abstract>
@ -38,7 +38,7 @@
<version>0.3</version>
<date>2003-10-22</date>
<initials>psa</initials>
<remark>Major overhaul. Moved entity and relationship elements to JEP-0123, and focused this JEP only on the information format itself, which in all cases must be contained within another protocol.</remark>
<remark>Major overhaul. Moved entity and relationship elements to XEP-0123, and focused this document only on the information format itself, which in all cases must be contained within another protocol.</remark>
</revision>
<revision>
<version>0.2</version>
@ -54,7 +54,7 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>Many Jabber protocols need to define metadata about "things" on the Jabber network; such things are not limited to entities that are addressable as JIDs (e.g., users, servers, services, and chatrooms) nor even to things that are addressable as &jep0060; or &jep0030; nodes (e.g., &jep0050;), but may include anything that Jabber entities can communicate about, including files sent via Jabber file transfer protocols (e.g., &jep0066; and &jep0096;), information published via pubsub protocols (e.g., &jep0118;), and other Jabber phenomena. To date, Jabber protocols have used disparate, specialized formats for capturing such meta-information. This JEP provides a generic information format that can be included whenever a protocol needs to define metadata about something on the network.</p>
<p>Many Jabber protocols need to define metadata about "things" on the Jabber network; such things are not limited to entities that are addressable as JIDs (e.g., users, servers, services, and chatrooms) nor even to things that are addressable as &xep0060; or &xep0030; nodes (e.g., &xep0050;), but may include anything that Jabber entities can communicate about, including files sent via Jabber file transfer protocols (e.g., &xep0066; and &xep0096;), information published via pubsub protocols (e.g., &xep0118;), and other Jabber phenomena. To date, Jabber protocols have used disparate, specialized formats for capturing such meta-information. This document provides a generic information format that can be included whenever a protocol needs to define metadata about something on the network.</p>
</section1>
<section1 topic='Background'>
<p>The format defined herein uses a simple "key-value" structure. Although this may seem contrary to the XML basis of Jabber technologies, there are at least two good reasons for pursuing this approach:</p>
@ -67,16 +67,16 @@
<section2 topic='Protocol Basics'>
<p>The "infobits" protocol defined herein provides a data format only. The container element is &lt;info/&gt;, which is qualified by the 'http://jabber.org/protocol/infobits' namespace. There is one allowable child of the &lt;info/&gt; element -- &lt;bundle/&gt; -- and one allowable child of the &lt;bundle/&gt; element -- &lt;bit/&gt;. In order to provide the relevant metadata, the &lt;info/&gt; element MAY contain an unbounded number of &lt;bundle/&gt; elements, each of which MAY contain an unbounded number of &lt;bit/&gt; elements.</p>
<p>Each &lt;bundle/&gt; element MUST possess a 'type' attribute, whose value specifies the aspect of reality to which the enclosed bits apply (e.g., geographical location). A &lt;bundle/&gt; element MAY also possess a 'context' attribute, whose value provides further specifying information about the kind of entities described by this bundle (e.g., a home address as opposed to a work address).</p>
<p>Each &lt;bit/&gt; element MUST possess a 'key' attribute, whose value specifies the name of the key (this MUST be an NMTOKEN as defined in &w3xml;). A &lt;bit/&gt; element MAY also possess a 'datatype' attribute, whose value specifies the datatype of the key (which SHOULD be a datatype specified in &w3xmlschema2; or in a registry of values maintained by the Jabber Registrar, such as those described in &jep0122;). The &lt;bit/&gt; element SHOULD contain XML character data that specifies the relevant value of the 'key'. A &lt;bundle/&gt; element MAY contain more than one &lt;bit/&gt; element with the same value for the 'key' attribute when necessary (e.g., two instances of 'weblog' if the person has multiple weblogs), but obviously SHOULD NOT do so if a collision would occur (e.g., two instances of 'lat' and 'lon' to define a geographical location).</p>
<p><em><strong>Note well:</strong> no keys are defined in this JEP. All such keys MUST be defined in separate specifications. Keys and associated values shown in this JEP are provided for explanatory purposes only.</em></p>
<p>Each &lt;bit/&gt; element MUST possess a 'key' attribute, whose value specifies the name of the key (this MUST be an NMTOKEN as defined in &w3xml;). A &lt;bit/&gt; element MAY also possess a 'datatype' attribute, whose value specifies the datatype of the key (which SHOULD be a datatype specified in &w3xmlschema2; or in a registry of values maintained by the Jabber Registrar, such as those described in &xep0122;). The &lt;bit/&gt; element SHOULD contain XML character data that specifies the relevant value of the 'key'. A &lt;bundle/&gt; element MAY contain more than one &lt;bit/&gt; element with the same value for the 'key' attribute when necessary (e.g., two instances of 'weblog' if the person has multiple weblogs), but obviously SHOULD NOT do so if a collision would occur (e.g., two instances of 'lat' and 'lon' to define a geographical location).</p>
<p><em><strong>Note well:</strong> no keys are defined in this document. All such keys MUST be defined in separate specifications. Keys and associated values shown in this document are provided for explanatory purposes only.</em></p>
</section2>
<section2 topic='Discovering Support'>
<p>When an entity is queried via &jep0030; regarding the features it supports, it SHOULD include the 'http://jabber.org/protocol/infobits' namespace.</p>
<p>When an entity is queried via &xep0030; regarding the features it supports, it SHOULD include the 'http://jabber.org/protocol/infobits' namespace.</p>
</section2>
</section1>
<section1 topic='Examples'>
<section2 topic='Requesting Geographical Location Information From Another Entity'>
<p>This set of examples is borrowed from &jep0080;.</p>
<p>This set of examples is borrowed from &xep0080;.</p>
<example caption='Requestor Requests Geolocation'><![CDATA[
<iq type='get'
from='linuxwolf@outer-planes.net/gabber2'
@ -173,7 +173,7 @@
]]></example>
</section2>
<section2 topic='Publishing Tune Information'>
<p>This set of examples is borrowed from &jep0118;.</p>
<p>This set of examples is borrowed from &xep0118;.</p>
<example caption='User Publishes Tune Information'><![CDATA[
<iq type='set'
from='stpeter@jabber.org/work'
@ -226,7 +226,7 @@
<p>Info key names registered with the Jabber Registrar MUST be considered as identifiers, not English-language words. For purposes of internationalization, an identifier SHOULD be rendered as a word or phrase that is appropriate to the end user's preferred language.</p>
</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'>
<section2 topic='Namespaces'>
@ -235,12 +235,12 @@
<section2 topic='Registries'>
<p>The Jabber Registrar shall maintain a registry of infobit keynames and associated information.</p>
<p>All keynames MUST begin with a short prefix string (letters and numbers only), followed by the '.' character used as a separator, followed by the name of the key as determined by the particular specification or organization that is identified with the prefix. Arbitrary keynames SHOULD begin with a prefix consisting of the capital 'X' character.</p>
<p>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 &jep0121;). 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 &jep0045;).</p>
<p>The Jabber Registrar shall at its discretion reserve certain keyname prefixes for use in specifying particular classes of information. One example is the prefix 'DC', which is reserved for use by infobits specified by the &DUBLINCORE; (for details, see &xep0121;). Furthermore, the Jabber Registrar shall reserve the "XMPP" prefix for infobits related to documents created by the &XMPPWG; or its successors, and shall reserve the upper-case versions of all protocol "shortnames" specified in Jabber Enhancement Proposals (e.g., a prefix of "MUC" for infobits related to &xep0045;).</p>
<p>In order to prevent naming collisions, infobits that will be used in public protocols that may interoperate with other protocols on the network SHOULD be registered with the Jabber Registrar, and MUST be so registered if they are defined in Jabber Enhancement Proposals (however, registration of private keys is NOT REQUIRED). Registration with the Jabber Registrar shall be considered to entail reservation of that infobit on the network, and a registered bit MUST NOT be re-used by other protocols and applications for purposes other than those implied by the registry entry.</p>
<p>In addition to the key name, the following data may be provided (but is not required) for each bit:</p>
<ol>
<li>datatype -- provide only if well-defined; otherwise assume string</li>
<li>doc -- the public identifier (e.g., JEP number or RFC number) of the document in which the info name is defined</li>
<li>doc -- the public identifier (e.g., XEP number or RFC number) of the document in which the info name is defined</li>
<li>valid values -- a series of &lt;value/&gt; elements, encapsulated within a &lt;values/&gt; parent whose 'type' attribute is set to "exhaustive" (these are the only valid values) or "nonexhaustive" (these are some of the valid values, but this list is not exhaustive and other values may be provided)</li>
</ol>
<p>The registry format is as follows:</p>
@ -307,4 +307,4 @@
</ol>
<p>Given these and other concerns, the primary author concluded that the best course would be to define an extensible XML protocol that can be processed using tools that are standard within existing Jabber/XMPP implementations, that allows only the entity itself to define metadata about itself, and that is under the control of the Jabber/XMPP community.</p>
</section1>
</jep>
</xep>

26
xep-0121.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>Dublin Core Infobits Mapping</title>
<abstract>NOTE: This proposal was retracted by the author on 2004-02-19.</abstract>
@ -16,7 +16,7 @@
<status>Retracted</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<dependencies>JEP-0120</dependencies>
<dependencies>XEP-0120</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>N/A</shortname>
@ -43,7 +43,7 @@
<version>0.3</version>
<date>2003-10-22</date>
<initials>psa</initials>
<remark>Updated to track changes in JEP-0120.</remark>
<remark>Updated to track changes in XEP-0120.</remark>
</revision>
<revision>
<version>0.2</version>
@ -59,13 +59,13 @@
</revision>
</header>
<section1 topic='Introduction'>
<p>&jep0120; 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 JEP specifies how to encapsulate one sort of metadata in infobits: the common metadata elements defined by the &DUBLINCORE;. Note well that this JEP is decidedly <em>not</em> meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the &REGISTRAR;, will specify additional infobits.</p>
<p>&xep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This document specifies how to encapsulate one sort of metadata in infobits: the common metadata elements defined by the &DUBLINCORE;. Note well that this document is decidedly <em>not</em> meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the &REGISTRAR;, will specify additional infobits.</p>
</section1>
<section1 topic='Dublin Core Metadata Terms'>
<p>The Dublin Core Metadata Initiative defines a number of common elements and element refinements that can be used to specify metadata about entities (especially but not exclusively publications). The semantics of any Dublin Core term can be represented as a Jabber infobit, where the infobit keyname consists of the term name (not label) prepended by a 'DC' prefix and a '.' separator character. Thus "DC.creator" is a valid infobit name and can be used to describe, for example, an IM user's relationship to the URI identifying the user's homepage or weblog. Infobit keynames beginning with the 'DC' prefix are reserved for &dcmiterms; only (the canonical list of these terms is available from the Dublin Core Metadata Initiative and is included here only for explanatory purposes).</p>
</section1>
<section1 topic='Examples'>
<p>The following example is borrowed from &jep0118;.</p>
<p>The following example is borrowed from &xep0118;.</p>
<example caption='User Publishes Tune Information'><![CDATA[
<iq type='set'
from='stpeter@jabber.org/work'
@ -106,13 +106,13 @@
]]></example>
</section1>
<section1 topic='Security Considerations'>
<p>This JEP introduces no security considerations above and beyond those already defined in JEP-0120.</p>
<p>This document introduces no security considerations above and beyond those already defined in XEP-0120.</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>The following is a submission to the infobits registry called for by JEP-0120.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>The following is a submission to the infobits registry called for by XEP-0120.</p>
<code><![CDATA[
<bit key='DC.title'/>
<bit key='DC.creator'/>
@ -193,4 +193,4 @@
<bit key='DC.MovingImage'/>
]]></code>
</section1>
</jep>
</xep>

48
xep-0122.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>Data Forms Validation</title>
<abstract>This JEP defines an extension to the Data Forms protocol that enables applications to specify additional validation guidelines.</abstract>
<abstract>This document defines an extension to the Data Forms protocol that enables applications to specify additional validation guidelines.</abstract>
&LEGALNOTICE;
<number>0122</number>
<status>Draft</status>
@ -15,13 +15,13 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0004</spec>
<spec>XEP-0004</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>xdata-validate</shortname>
<schemaloc>
<url>http://jabber.org/protocol/xdata-validate/xdata-validate.xsd</url>
<url>http://www.xmpp.org/schemas/xdata-validate.xsd</url>
</schemaloc>
<registry/>
&linuxwolf;
@ -41,7 +41,7 @@
<version>0.7</version>
<date>2004-08-23</date>
<initials>lw</initials>
<remark>Replaced method attribute with dedicated elements; removed Formal Definition section in favor of defining requirements within the use-cases and XML schema; included display considerations; added reference to JEP-0115.</remark>
<remark>Replaced method attribute with dedicated elements; removed Formal Definition section in favor of defining requirements within the use-cases and XML schema; included display considerations; added reference to XEP-0115.</remark>
</revision>
<revision>
<version>0.6</version>
@ -81,10 +81,10 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&jep0004; ("x:data") provides a simple and interoperable way to request and present information for both applications and humans. However, the simple nature of "x:data" requires the form interpreter at times to guess as to exactly what type of information is being requested or provided. This JEP builds upon "x:data" to provide this additional validation.</p>
<p>&xep0004; ("x:data") provides a simple and interoperable way to request and present information for both applications and humans. However, the simple nature of "x:data" requires the form interpreter at times to guess as to exactly what type of information is being requested or provided. This document builds upon "x:data" to provide this additional validation.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The requirements for this JEP are:</p>
<p>The requirements for this document are:</p>
<ul>
<li>Backwards compatible with the existing "x:data" protocol.</li>
<li>Provide extended datatypes (such as dates, times, and numbers).</li>
@ -95,7 +95,7 @@
</ul>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>This JEP defines a new namespace, "http://jabber.org/protocols/xdata-validate". The root element for this namespace is &lt;validate/&gt;, and MUST be contained within a &lt;field/&gt; element (qualified by the 'jabber:x:data' namespace) for each <cite>Data Forms</cite> field that possesses additional validation information.</p>
<p>This document defines a new namespace, "http://jabber.org/protocols/xdata-validate". The root element for this namespace is &lt;validate/&gt;, and MUST be contained within a &lt;field/&gt; element (qualified by the 'jabber:x:data' namespace) for each <cite>Data Forms</cite> field that possesses additional validation information.</p>
<section2 topic='Datatype Validation' anchor='usecases-datatypes'>
<p>The simplest usage is to provide a more-granular datatype for a &lt;field/&gt; element used in <cite>Data Forms</cite>. To provide this datatype information, a &lt;validate/&gt; element is included whose 'datatype' attribute specifies the data type of any &lt;value/&gt; contained within the &lt;field/&gt; element:</p>
<example caption='Field with extended datatype'><![CDATA[
@ -114,7 +114,7 @@
</ul>
</section2>
<section2 topic='Validation Methods' anchor='usecases-validation'>
<p>In addition to datatypes, the validation method can also be provided. The method is specified via a child element. The validation methods defined in this JEP are:</p>
<p>In addition to datatypes, the validation method can also be provided. The method is specified via a child element. The validation methods defined in this document are:</p>
<ul>
<li>&lt;basic/&gt; for validation only against the datatype itself</li>
<li>&lt;open/&gt; for open-ended validation against the datatype</li>
@ -222,7 +222,7 @@
<p>If an implementation does not understand the specified datatype, it MUST validate according to the default "xs:string" datatype. If an implementation does not understand the specified method, it MUST validate according to the &lt;basic/&gt; method.</p>
</section2>
<section2 topic='Namespacing' anchor='impl-ns'>
<p>While all elements associated with this JEP MUST be qualified by the 'http://jabber.org/protocol/xdata-validate' namespace, explicitly declaring the default namespace for each instance can be overly verbose. However, Jabber/XMPP implementations have historically been very lax regarding namespacing, thus requiring some careful use of prefixes.</p>
<p>While all elements associated with this document MUST be qualified by the 'http://jabber.org/protocol/xdata-validate' namespace, explicitly declaring the default namespace for each instance can be overly verbose. However, Jabber/XMPP implementations have historically been very lax regarding namespacing, thus requiring some careful use of prefixes.</p>
<p>The use of namespace prefixes is RECOMMENDED for large forms, to reduce the data size. To maintain the highest level of compatibility, implementations sending the form using prefixes SHOULD use the namespace prefix "xdv", and SHOULD declare the namespace prefix mapping in the ancestor &lt;x xmlns='jabber:x:data'/&gt; element:</p>
<example caption='Example of recommended namespace prefixing'><![CDATA[
<x xmlns='jabber:x:data'
@ -243,13 +243,13 @@
]]></example>
</section2>
<section2 topic='Internationalization/Localization' anchor='impl-i18n'>
<p>This JEP relies on the internationalization/localization mechanisms provided by &xmppcore;. As much as possible, all datatype formats MUST be locale-independent.</p>
<p>This document relies on the internationalization/localization mechanisms provided by &xmppcore;. As much as possible, all datatype formats MUST be locale-independent.</p>
</section2>
<section2 topic='Form Submissions' anchor='impl-submit'>
<p>Form processors MUST NOT assume that a form with validation has actually been validated when submitted. There is no realistic expectation that form interpreters honor validation.</p>
</section2>
<section2 topic='Existing Protocols' anchor='impl-proto'>
<p>While this JEP is compatible with the existing "x:data" definition, form providers SHOULD first determine support for it, using either &jep0115; if presence-aware or &jep0030;. This is especially important for limited-connection and/or limited-capabilities devices, such as cell phones.</p>
<p>While this document is compatible with the existing "x:data" definition, form providers SHOULD first determine support for it, using either &xep0115; if presence-aware or &xep0030;. This is especially important for limited-connection and/or limited-capabilities devices, such as cell phones.</p>
</section2>
<section2 topic='Display Considerations' anchor='impl-display'>
<p>Although primarily intended for validating form submission, validation MAY have an impact on display, and MAY be applied to data forms that are not submitted (e.g. 'result' type forms). The following table outlines which field types a particular validation method is or is not appropriate for, and how a display SHOULD interpret the validation methods if considered<note>If a particular field type is not listed, the display MAY include validation support, but is not expected to do so.</note>:</p>
@ -328,18 +328,18 @@
</section2>
</section1>
<section1 topic='Security Considerations' anchor='sec'>
<p>This JEP introduces no security concerns above and beyond those specified in <cite>JEP-0004: Data Forms</cite>.</p>
<p>This document introduces no security concerns above and beyond those specified in <cite>XEP-0004: Data Forms</cite>.</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='registar'>
<section1 topic='XMPP Registrar Considerations' anchor='registar'>
<section2 topic='Protocol Namespaces' anchor='registar-ns'>
<p>The Jabber Registrar includes 'http://jabber.org/protocol/xdata-validate' in its registry of protocol namespaces.</p>
<p>The XMPP Registrar includes 'http://jabber.org/protocol/xdata-validate' in its registry of protocol namespaces.</p>
</section2>
<section2 topic='Registries' anchor='registar-reg'>
<section3 topic='Datatype Prefixes Registry' anchor='registar-reg-prefixes'>
<p>The Jabber Registrar maintains a registry of datatype prefixes used in the context of Data Forms Validation (see <link url='http://www.jabber.org/registrar/xdv-prefixes.html'>http://www.jabber.org/registrar/xdv-prefixes.html</link>), where each prefix denotes a group of related datatypes.</p>
<p>The XMPP Registrar maintains a registry of datatype prefixes used in the context of Data Forms Validation (see <link url='http://www.jabber.org/registrar/xdv-prefixes.html'>http://www.jabber.org/registrar/xdv-prefixes.html</link>), where each prefix denotes a group of related datatypes.</p>
<section4 topic='Process' anchor='registrar-reg-prefixes-process'>
&REGPROCESS;
<code><![CDATA[
@ -352,12 +352,12 @@
<p>The registrant may register more than one prefix at a time, each contained in a separate &lt;datatype-prefix/&gt; element.</p>
</section4>
<section4 topic='Initial Submission' anchor='registrar-reg-prefixes-init'>
<p>As part of this JEP, the following datatype prefixes shall be registered:</p>
<p>As part of this document, the following datatype prefixes shall be registered:</p>
<code><![CDATA[
<datatype-prefix>
<prefix>x</prefix>
<desc>An ad-hoc datatype</desc>
<doc>JEP-0122</doc>
<doc>XEP-0122</doc>
</datatype-prefix>
<datatype-prefix>
<prefix>xs</prefix>
@ -368,7 +368,7 @@
</section4>
</section3>
<section3 topic='Datatypes Registry' anchor='registar-reg-datatypes'>
<p>The Jabber Registrar maintains a registry of datatypes used in the context of Data Forms Validation (see <link url='http://www.jabber.org/registrar/xdv-datatypes.html'>http://www.jabber.org/registrar/xdv-datatypes.html</link>), where each datatype name includes the relevant prefix (e.g., "xs:anyURI").</p>
<p>The XMPP Registrar maintains a registry of datatypes used in the context of Data Forms Validation (see <link url='http://www.jabber.org/registrar/xdv-datatypes.html'>http://www.jabber.org/registrar/xdv-datatypes.html</link>), where each datatype name includes the relevant prefix (e.g., "xs:anyURI").</p>
<section4 topic='Process' anchor='registrar-reg-datatypes-process'>
&REGPROCESS;
<code><![CDATA[
@ -550,4 +550,4 @@
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

30
xep-0123.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>Entity Metadata</title>
<abstract>NOTE: This proposal was retracted by the author on 2004-02-19.</abstract>
@ -16,7 +16,7 @@
<status>Retracted</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<dependencies>XMPP Core, XMPP IM, JEP-0030, JEP-0120</dependencies>
<dependencies>XMPP Core, XMPP IM, XEP-0030, XEP-0120</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>N/A</shortname>
@ -25,7 +25,7 @@
<version>0.3</version>
<date>2003-12-16</date>
<initials>psa</initials>
<remark>Incorporated infobits changes and vCard infobit mappings; metadata about relationships to be moved to forthcoming JEP.</remark>
<remark>Incorporated infobits changes and vCard infobit mappings; metadata about relationships to be moved to forthcoming specification.</remark>
</revision>
<revision>
<version>0.2</version>
@ -37,11 +37,11 @@
<version>0.1</version>
<date>2003-10-22</date>
<initials>psa</initials>
<remark>Initial version, split off from JEP-0120.</remark>
<remark>Initial version, split off from XEP-0120.</remark>
</revision>
</header>
<section1 topic='Background and Requirements'>
<p>Traditionally, the only mechanism for communicating detailed information about entities on the Jabber network has been an XML version of the vCard format for electronic business cards (see &jep0054;). Unfortunately, the vCard format has several major drawbacks:</p>
<p>Traditionally, the only mechanism for communicating detailed information about entities on the Jabber network has been an XML version of the vCard format for electronic business cards (see &xep0054;). Unfortunately, the vCard format has several major drawbacks:</p>
<ol>
<li>It is mainly limited to data about persons (although it has been used on the Jabber network to describe things like servers).</li>
<li>The format contains relatively few data fields.</li>
@ -51,14 +51,14 @@
</ol>
<p>It is becoming increasingly important to define a robust, extensible format for describing entities on the Jabber network. Such a format should be:</p>
<ol>
<li>Applicable not just to people but to any entity on the network, including but not limited to servers, components, bots, &jep0045; rooms, &jep0060; nodes, and in general anything that can be addressed as a Jabber ID (as defined in &xmppcore;).</li>
<li>Applicable not just to people but to any entity on the network, including but not limited to servers, components, bots, &xep0045; rooms, &xep0060; nodes, and in general anything that can be addressed as a Jabber ID (as defined in &xmppcore;).</li>
<li>Usable in encapsulating any information about the entity itself (name, address, description, title, etc.).</li>
<li>Extensible enough to handle any metadata that may be needed for current and future applications (including, at a minimum, everything that can be defined in vCard); it must be possible to use it for public protocols defined by the IETF or Jabber Software Foundation as well as for custom or private protocols.</li>
<li>Well-defined enough, through datatyping and public registries where applicable, to enable robust searching and filtering based on defined data fields and their values.</li>
</ol>
</section1>
<section1 topic='Protocol'>
<p>Information about entities is provided using the &jep0120; protocol and registered infobit keynames (mainly those specified in &jep0125; although entity metadata is by no means limited to vCard information and could include infobits such as those specified in &jep0121;). The metadata is discovered by interacting with a common &jep0030; node named "metadata". The queried entity replies with a service discovery result containing any infobits that the entity wishes to reveal about itself to the requesting entity. This information is always metadata about the entity itself, not any other entities or any relationships that the entity may have to other entities.</p>
<p>Information about entities is provided using the &xep0120; protocol and registered infobit keynames (mainly those specified in &xep0125; although entity metadata is by no means limited to vCard information and could include infobits such as those specified in &xep0121;). The metadata is discovered by interacting with a common &xep0030; node named "metadata". The queried entity replies with a service discovery result containing any infobits that the entity wishes to reveal about itself to the requesting entity. This information is always metadata about the entity itself, not any other entities or any relationships that the entity may have to other entities.</p>
</section1>
<section1 topic='Use Cases'>
<section2 topic='Discovering Support'>
@ -126,18 +126,18 @@
<li>directories of pubsub nodes</li>
<li>server directories</li>
</ul>
<p>Although such directories will be a valuable addition to the network, it is imperative to understand that the canonical source for metadata about an entity is the entity itself. Mechanisms for keeping directories synchronized with entities are outside the scope of this JEP, and in any case a directory may not be privy to all information about an entity (since in general a user should publish to a directory only the information that he or she deems world-readable).</p>
<p>Directories SHOULD require registration using &jep0077;. Before registering with a directory, an entity SHOULD adjust its access controls or privacy rules accordingly, including appropriate definition of classes and addition of the directory server's JID to the relevant privacy rules. Upon accepting registration from an entity, a directory SHOULD immediately send a metadata request to the registering entity. Synchronization of metadata is a matter for the directory implementation to determine, and perhaps negotiate with the registering entity; all such synchronization and negotiation is out of scope for this JEP.</p>
<p>Although such directories will be a valuable addition to the network, it is imperative to understand that the canonical source for metadata about an entity is the entity itself. Mechanisms for keeping directories synchronized with entities are outside the scope of this document, and in any case a directory may not be privy to all information about an entity (since in general a user should publish to a directory only the information that he or she deems world-readable).</p>
<p>Directories SHOULD require registration using &xep0077;. Before registering with a directory, an entity SHOULD adjust its access controls or privacy rules accordingly, including appropriate definition of classes and addition of the directory server's JID to the relevant privacy rules. Upon accepting registration from an entity, a directory SHOULD immediately send a metadata request to the registering entity. Synchronization of metadata is a matter for the directory implementation to determine, and perhaps negotiate with the registering entity; all such synchronization and negotiation is out of scope for this document.</p>
</section1>
<section1 topic='Security Considerations'>
<p>Metadata MAY be world-readable. Entities MUST take care to ensure that they exercise proper control over access to such information. Users of IM clients SHOULD be warned that their data may be world-readable and be given the option to not publish such information or control it via appropriate mechanisms (such as privacy rules).</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'>
<section1 topic='XMPP Registrar Considerations'>
<section2 topic='Service Discovery Nodes'>
<p>Upon advancement of this proposal to a status of Draft, the &REGISTRAR; shall add the 'metadata' node to its registry of common Service Discovery nodes.</p>
</section2>
</section1>
</jep>
</xep>

48
xep-0124.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>HTTP Binding</title>
<abstract>This JEP defines a binding of Jabber/XMPP communications to a transport layer of HTTP rather than TCP.</abstract>
<abstract>This document defines a binding of XMPP communications to a transport layer of HTTP rather than TCP.</abstract>
&LEGALNOTICE;
<number>0124</number>
<status>Draft</status>
@ -23,7 +23,7 @@
<supersededby/>
<shortname>httpbind</shortname>
<schemaloc>
<url>http://jabber.org/protocol/httpbind/httpbind.xsd</url>
<url>http://www.xmpp.org/schemas/httpbind.xsd</url>
</schemaloc>
&ianpaterson;
&dizzyd;
@ -126,11 +126,11 @@
</revision>
</header>
<section1 topic="Introduction" anchor='intro'>
<p>&xmppcore; defines XML streams bound to TCP (see &rfc0793;) as the standard transport layer for Jabber/XMPP communications. However, the binding of XMPP to TCP is not always feasible because of client runtime environment and/or network constraints. This JEP describes the usage of the Hypertext Transfer Protocol (HTTP, see &rfc2068; and &rfc1945;) as an alternative transport binding that supports such constrained environments, normally via deployment of a specialized server-side connection manager that communicates with clients via HTTP rather than TCP.</p>
<p>Before the authors pursued publication of this JEP, other approaches were explored. One possible approach might have been to apply state to a series of HTTP transactions via HTTP "cookies" as specified in &rfc2965;. However, there are several significant computing platforms which provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers. Therefore the cookie approach was rejected.</p>
<p>Another approach might have been to modify or extend &jep0025;. This informational protocol has been used by Jabber clients without runtime constraints to access XMPP servers from behind firewalls. Unfortunately, the method defined in JEP-0025 also depends on cookies, does not meet most of the requirements described below, and cannot be extended without breaking all existing implementations.</p>
<p>Therefore, this JEP specifies a new way of transporting XMPP via HTTP. All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single &lt;body/&gt; XML wrapper element (not to be confused with the &lt;body/&gt; child of the &lt;message/&gt; stanza as defined in &xmppim;), which encapsulates zero or more XML stanzas.</p>
<p>Although this JEP documents some XMPP-specific features, the binding is not part of XMPP. In fact, the protocol is extensible and could be used to implement any bidirectional stream of XML stanzas.</p>
<p>&xmppcore; defines XML streams bound to TCP (see &rfc0793;) as the standard transport layer for Jabber/XMPP communications. However, the binding of XMPP to TCP is not always feasible because of client runtime environment and/or network constraints. This document describes the usage of the Hypertext Transfer Protocol (HTTP, see &rfc2068; and &rfc1945;) as an alternative transport binding that supports such constrained environments, normally via deployment of a specialized server-side connection manager that communicates with clients via HTTP rather than TCP.</p>
<p>Before the authors pursued publication of this document, other approaches were explored. One possible approach might have been to apply state to a series of HTTP transactions via HTTP "cookies" as specified in &rfc2965;. However, there are several significant computing platforms which provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers. Therefore the cookie approach was rejected.</p>
<p>Another approach might have been to modify or extend &xep0025;. This informational protocol has been used by Jabber clients without runtime constraints to access XMPP servers from behind firewalls. Unfortunately, the method defined in XEP-0025 also depends on cookies, does not meet most of the requirements described below, and cannot be extended without breaking all existing implementations.</p>
<p>Therefore, this document specifies a new way of transporting XMPP via HTTP. All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single &lt;body/&gt; XML wrapper element (not to be confused with the &lt;body/&gt; child of the &lt;message/&gt; stanza as defined in &xmppim;), which encapsulates zero or more XML stanzas.</p>
<p>Although this specification documents some XMPP-specific features, the binding is not part of XMPP. In fact, the protocol is extensible and could be used to implement any bidirectional stream of XML stanzas.</p>
</section1>
<section1 topic="Terminology" anchor='terms'>
<section2 topic="HTTP Terms" anchor='terms-http'>
@ -170,7 +170,7 @@ Connection Manager
|
HTTP Client
]]></code>
<p>This JEP addresses communications between an HTTP client and the connection manager only. It does not address communications between the connection manager and the XMPP server, since such communications are implementation-specific (e.g., the connection manager and the XMPP server may use &jep0114; or an API defined by the XMPP server implementation in order to communicate; alternatively, the XMPP server may natively support the HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity).</p>
<p>This document addresses communications between an HTTP client and the connection manager only. It does not address communications between the connection manager and the XMPP server, since such communications are implementation-specific (e.g., the connection manager and the XMPP server may use &xep0114; or an API defined by the XMPP server implementation in order to communicate; alternatively, the XMPP server may natively support the HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity).</p>
<p>Furthermore, no aspect of the HTTP binding limits its use to client-to-server communications; i.e., it could be used for server-to-server or component-to-server communications as well (probably through a slight change to the XML schema). However, this document focuses exclusively on use of the HTTP binding by clients that cannot maintain persistent TCP connections to a server and that therefore cannot use the TCP binding defined in <cite>RFC 3920</cite>. We assume that servers and components are under no such restrictions and thus would use the TCP binding.</p>
</section1>
<section1 topic="HTTP Version and HTTP Headers" anchor='http'>
@ -179,7 +179,7 @@ Connection Manager
</section1>
<section1 topic="Compression" anchor='compression'>
<p>Clients MAY include an HTTP Accept-Encoding header in any request. If the connection manager receives a request with an Accept-Encoding header, it MAY include an HTTP Content-Encoding header in the response (indicating one of the encodings specified in the request) and compress the response body accordingly.</p>
<p>TLS compression (as defined in <cite>RFC 3920</cite>) and Stream Compression (as defined in &jep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer and with the 'accept' attribute (see the <link url="#session-create">Session Creation</link> section below). TLS compression and Stream Compression SHOULD NOT be used simultaneously with HTTP content encoding.</p>
<p>TLS compression (as defined in <cite>RFC 3920</cite>) and Stream Compression (as defined in &xep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer and with the 'accept' attribute (see the <link url="#session-create">Session Creation</link> section below). TLS compression and Stream Compression SHOULD NOT be used simultaneously with HTTP content encoding.</p>
</section1>
<section1 topic="&lt;body/&gt; Wrapper Element" anchor='wrapper'>
<p>The body of each HTTP request and response contains a single &lt;body/&gt; wrapper element. The &lt;body/&gt; element MUST contain zero or more complete XML elements. It MUST NOT contain partial XML elements.</p>
@ -225,7 +225,7 @@ Content-Length: 104
wait='60'
xml:lang='en'
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<p>Note: Unlike the protocol defined in JEP-0025, an opening &lt;stream:stream&gt; tag is not sent. The protocol defined herein abstracts from XML streams between the connection manager and the client. Any XML streams between the connection manager and an XMPP server are the responsibility of the connection manager.</p>
<p>Note: Unlike the protocol defined in XEP-0025, an opening &lt;stream:stream&gt; tag is not sent. The protocol defined herein abstracts from XML streams between the connection manager and the client. Any XML streams between the connection manager and an XMPP server are the responsibility of the connection manager.</p>
<p>Note: All requests after the first one MUST include a valid 'sid' attribue (provided by the connection manager in the session creation response below). The initialization request is unique in that the &lt;body/&gt; element MUST NOT possess a 'sid' attribute.</p>
</section2>
<section2 topic="Session Creation" anchor='session-create'>
@ -252,7 +252,7 @@ Content-Length: 128
secure='true'
charsets='ISO_8859-1 ISO-2022-JP'
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<p>Note: The 'authid' attribute contains the value of the XMPP stream ID generated by the XMPP server. The connection manager MUST retrieve the stream ID and pass it unmodified to the client. This value is needed by the client to successfully complete digest authentication using &jep0078; (see the <link url="#preconditions-iqauth">jabber:iq:auth</link> section below).</p>
<p>Note: The 'authid' attribute contains the value of the XMPP stream ID generated by the XMPP server. The connection manager MUST retrieve the stream ID and pass it unmodified to the client. This value is needed by the client to successfully complete digest authentication using &xep0078; (see the <link url="#preconditions-iqauth">jabber:iq:auth</link> section below).</p>
<p>Note: If the 'authid' attribute is not included in the connection manager's response to the session creation request (e.g., because the connection manager has not yet received a stream ID from the XMPP server), then the client SHOULD send empty request elements (see the "Requesting XML Stanzas" example below) until it receives a response with an 'authid' attribute. In any case, the connection manager MUST return the 'authid' in a response to the client as soon as possible after it receives the stream ID from the XMPP server.</p>
<p>Separate 'sid' and 'authid' attributes are required because the connection manager is not necessarily part of a single XMPP server (e.g., it may handle HTTP connections on behalf of multiple XMPP servers).</p>
<p>If it established a secure connection to the XMPP server (as defined in <link url='#session'>Initiating an HTTP Session</link>), then the connection manager SHOULD include the 'secure' attribute set to 'true' or '1' in the response to the client that contains the 'authid' attribute.</p>
@ -455,7 +455,7 @@ Content-Length: 175
</section2>
<section2 topic="jabber:iq:auth" anchor='preconditions-iqauth'>
<p>A success case for simultaneous authentication, resource binding, and IM session creation using the original "jabber:iq:auth" protocol is shown below. For further details regarding use of this protocol, refer to JEP-0078. If digest authentication is used, then the stream ID value used to compute the hashed password MUST be the value of the 'authid' attribute provided by the connection manager in the response to the initialization element or in a subsequent response (see the <link url="#session-create">Session Creation</link> section above).</p>
<p>A success case for simultaneous authentication, resource binding, and IM session creation using the original "jabber:iq:auth" protocol is shown below. For further details regarding use of this protocol, refer to XEP-0078. If digest authentication is used, then the stream ID value used to compute the hashed password MUST be the value of the 'authid' attribute provided by the connection manager in the response to the initialization element or in a subsequent response (see the <link url="#session-create">Session Creation</link> section above).</p>
<example caption="Non-SASL authentication request">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.jabber.org
@ -839,12 +839,12 @@ Content-Length: 68
<tr><td><strong>HTTP Conditions</strong></td><td>The connection manager responds to an invalid client request with a standard HTTP error. These are used for binding syntax errors, possible attacks, etc. Note that constrained clients are unable to differentiate between HTTP errors.</td></tr>
<tr><td><strong>Terminal Binding Conditions</strong></td><td>These error conditions may be read by constrained clients. They are used for connection manager problems, abstracting stream errors, and communication problems between the connection manager and the XMPP server.</td></tr>
<tr><td><strong>Recoverable Binding Conditions</strong></td><td>These report communication problems between the connection manager and the client. They do not terminate the session. Clients recover from these errors by resending all the preceding &lt;body/&gt; wrapper elements that have not received responses.</td></tr>
<tr><td><strong>XMPP Stanza Conditions</strong></td><td>XMPP errors relating to XML stanzas within &lt;body/&gt; wrapper elements are, in general, defined in the appropriate RFC or JEP. They do not terminate the session. (An example of such usage is shown in <link url="#preconditions-iqauth">jabber:iq:auth</link> above.)</td></tr>
<tr><td><strong>XMPP Stanza Conditions</strong></td><td>XMPP errors relating to XML stanzas within &lt;body/&gt; wrapper elements are, in general, defined in the appropriate RFC or XEP. They do not terminate the session. (An example of such usage is shown in <link url="#preconditions-iqauth">jabber:iq:auth</link> above.)</td></tr>
</table>
<p>Full descriptions are provided below.</p>
<section2 topic='HTTP Conditions' anchor='errorstatus-http'>
<p>The following HTTP error and status codes are used in particular ways by this protocol (other HTTP error and status codes may be used as appropriate). Upon receiving an HTTP error (400, 403, 404), the HTTP client MUST consider the HTTP session to be null and void.</p>
<p>Note: These are pure HTTP codes as defined in the HTTP specification, and are not to be confused with the HTTP-style error codes traditionally used in Jabber protocols and documented in &jep0086;.</p>
<p>Note: These are pure HTTP codes as defined in the HTTP specification, and are not to be confused with the HTTP-style error codes traditionally used in Jabber protocols and documented in &xep0086;.</p>
<table caption='HTTP Error and Status Codes'>
<tr>
<th>Code</th>
@ -971,7 +971,7 @@ Content-Length: 68
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
</section2>
<section2 topic='XMPP Stanza Conditions' anchor='errorstatus-stanza'>
<p>Application-level error conditions will normally be generated by a third entity (e.g., an IM contact) and routed to the client through the connection manager; therefore they are out of scope for the transport binding defined herein and are described in the appropriate RFC or JEP.</p>
<p>Application-level error conditions will normally be generated by a third entity (e.g., an IM contact) and routed to the client through the connection manager; therefore they are out of scope for the transport binding defined herein and are described in the appropriate RFC or XEP.</p>
<p>However, it is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform a server that the connection has died). In this case, the connection manager would return an error to the server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of <cite>RFC 3921</cite>:</p>
<ol>
<li>If the delivered stanza was &PRESENCE;, silently drop the stanza and do not return an error to the sender.</li>
@ -992,12 +992,12 @@ Content-Length: 68
<li>If the client sends a wrapper element that is part of a 'secure session' over a connection that either is not encrypted or uses a different certificate then the connection manager SHOULD simply close the connection. The connection manager SHOULD NOT terminate the session since that would facilitate denial of service attacks.</li>
</ul>
<p>The session identifier (SID) and initial request identifier (RID) are security-critical and therefore MUST be both unpredictable and nonrepeating (see &rfc1750; for recommendations regarding randomness of SIDs and initial RIDs for security purposes).</p>
<p>In cases where the connection manager acts as a 'proxy' independent of the XMPP server, it creates another security vulnerability in addition to those on the XMPP servers. It is RECOMMENDED that clients ensure the security of stanzas sent through the connection manager (and XMPP servers) in both directions by encrypting them end-to-end (e.g., by establishing &jep0116;).</p>
<p>In cases where the connection manager acts as a 'proxy' independent of the XMPP server, it creates another security vulnerability in addition to those on the XMPP servers. It is RECOMMENDED that clients ensure the security of stanzas sent through the connection manager (and XMPP servers) in both directions by encrypting them end-to-end (e.g., by establishing &xep0116;).</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/httpbind' in its registry of protocol namespaces.</p>
</section2>
@ -1016,7 +1016,7 @@ Content-Length: 68
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
JEP-0124: http://www.jabber.org/jeps/jep-0124.html
XEP-0124: http://www.xmpp.org/extensions/xep-0124.html
</xs:documentation>
</xs:annotation>
@ -1098,4 +1098,4 @@ Content-Length: 68
</xs:schema>
]]></code>
</section1>
</jep>
</xep>

26
xep-0125.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>vCard Infobits Mapping</title>
<abstract>NOTE: This proposal was retracted by the author on 2004-02-19.</abstract>
@ -16,7 +16,7 @@
<status>Retracted</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<dependencies>JEP-0120</dependencies>
<dependencies>XEP-0120</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>N/A</shortname>
@ -25,14 +25,14 @@
<version>0.1</version>
<date>2003-12-15</date>
<initials>psa</initials>
<remark>Initial version, split off from version 0.5 of JEP-0121 (with revisions to more clearly map vCard elements); further mapping and description required.</remark>
<remark>Initial version, split off from version 0.5 of XEP-0121 (with revisions to more clearly map vCard elements); further mapping and description required.</remark>
</revision>
</header>
<section1 topic='Introduction'>
<p>&jep0120; 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 JEP 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 &jep0054;. Note well that this JEP is decidedly <em>not</em> meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the &REGISTRAR;, will specify additional infobits.</p>
<p>&xep0120; defines a protocol for capturing granular information (or "infobits") about users, servers, services, rooms, nodes, commands, files, and other phenomena on the Jabber/XMPP network; however, that document defines the protocol only, not the infobits themselves. This document specifies how to encapsulate one sort of metadata in infobits: the metadata elements about entities defined by &rfc2426; (supplemented by vCard-like metadata that is not defined in RFC 2426), thus enabling the Jabber community to supersede &xep0054;. Note well that this document is decidedly <em>not</em> meant to provide an exhaustive catalog of possible infobits. Future registrations, whether in Jabber Enhancement Proposals or direct submissions to the &REGISTRAR;, will specify additional infobits.</p>
</section1>
<section1 topic='vCard Mapping'>
<p>In order to supersede the vCard-XML protocol currently in use within the Jabber community, it is necessary to define infobits that correspond to the data elements defined by the vCard-XML DTD (more precisely, the vCard Profile Features specified in section 3 of RFC 2426). These are shown in the following table. (Note: this mapping uses the vCard entity names specified in &dawson3;, not those specified in JEP-0054.)</p>
<p>In order to supersede the vCard-XML protocol currently in use within the Jabber community, it is necessary to define infobits that correspond to the data elements defined by the vCard-XML DTD (more precisely, the vCard Profile Features specified in section 3 of RFC 2426). These are shown in the following table. (Note: this mapping uses the vCard entity names specified in &dawson3;, not those specified in XEP-0054.)</p>
<table caption='Mapping of vCard Fields'>
<tr>
<th>Infobit Key</th>
@ -260,13 +260,13 @@
</table>
</section1>
<section1 topic='Security Considerations'>
<p>This JEP introduces no security considerations above and beyond those already defined in JEP-0120.</p>
<p>This document introduces no security considerations above and beyond those already defined in XEP-0120.</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>The following is a submission to the infobits registry called for by JEP-0120.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>The following is a submission to the infobits registry called for by XEP-0120.</p>
<section2 topic='vCard Mapping Infobits'>
<p>To follow.</p>
</section2>
@ -274,4 +274,4 @@
<p>To follow.</p>
</section2>
</section1>
</jep>
</xep>

2
xep-0126.xml
View File

@ -415,7 +415,7 @@
<section1 topic='IANA Considerations' anchor='impl'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='Jabber Registrar Considerations' anchor='impl'>
<section1 topic='XMPP Registrar Considerations' anchor='impl'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this specification.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>

30
xep-0127.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>Common Alerting Protocol (CAP) Over XMPP</title>
<abstract>This JEP specifies a method for sending Common Alerting Protocol (CAP) data over XMPP.</abstract>
<abstract>This document specifies a method for sending Common Alerting Protocol (CAP) data over XMPP.</abstract>
&LEGALNOTICE;
<number>0127</number>
<status>Active</status>
@ -37,7 +37,7 @@
<version>0.2</version>
<date>2004-11-09</date>
<initials>psa</initials>
<remark>Added references to JEP-0033 and JEP-0131.</remark>
<remark>Added references to XEP-0033 and XEP-0131.</remark>
</revision>
<revision>
<version>0.1</version>
@ -55,8 +55,8 @@
<section1 topic='Protocol'>
<p>Because the alerts and notifications structured via CAP require a "push" medium, they SHOULD be sent via the XML &MESSAGE; stanza defined in <cite>XMPP Core</cite>. The message could be sent using either of the following methods:</p>
<ol>
<li>Directly from the sender to a single recipient, a list of recipients (using &jep0033;), or a &jep0045; room</li>
<li>Published to a list of subscribers via &jep0060;</li>
<li>Directly from the sender to a single recipient, a list of recipients (using &xep0033;), or a &xep0045; room</li>
<li>Published to a list of subscribers via &xep0060;</li>
</ol>
<p>Both methods are described below.</p>
<section2 topic='Direct Messages'>
@ -112,7 +112,7 @@
]]></example>
</section2>
<section2 topic='PubSub'>
<p>The publish-subscribe protocol defined in JEP-0060 provides a way to send information to a number of subscribers, and to control the list of subscribers.</p>
<p>The publish-subscribe protocol defined in XEP-0060 provides a way to send information to a number of subscribers, and to control the list of subscribers.</p>
<p>The following example shows Example A.2 from the CAP specification published to a pubsub node.</p>
<example caption='An Alert Published to a PubSub Node'><![CDATA[
<iq type='set'
@ -227,16 +227,16 @@
</section2>
</section1>
<section1 topic='Security Considerations'>
<p>Security considerations for CAP are defined in <strong>Common Alerting Protocol, v. 1.0</strong>; security considerations for XMPP are defined in <strong>RFC 3920: XMPP Core</strong>; security considerations for the XMPP publish-subscribe extension are defined in <cite>JEP-0060: Publish Subscribe</cite>.</p>
<p>Furthermore, it may be appropriate to include the "Classification", "Distribute", and/or "Store" headers specified in &jep0131; in order to safeguard CAP data.</p>
<p>Security considerations for CAP are defined in <strong>Common Alerting Protocol, v. 1.0</strong>; security considerations for XMPP are defined in <strong>RFC 3920: XMPP Core</strong>; security considerations for the XMPP publish-subscribe extension are defined in <cite>XEP-0060: Publish Subscribe</cite>.</p>
<p>Furthermore, it may be appropriate to include the "Classification", "Distribute", and/or "Store" headers specified in &xep0131; in order to safeguard CAP data.</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>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this JEP.</p>
<section1 topic='XMPP Registrar Considerations'>
<p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
</section1>
<section1 topic='XML Schema'>
<p>The CAP information format is defined by an XML schema. The reader is referred to the CAP specification for the relevant schema definition.</p>
</section1>
</jep>
</xep>

36
xep-0128.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>Service Discovery Extensions</title>
<abstract>This JEP specifies best practices for including extended information in Service Discovery results.</abstract>
<abstract>This document specifies best practices for including extended information in Service Discovery results.</abstract>
&LEGALNOTICE;
<number>0128</number>
<status>Active</status>
@ -15,9 +15,9 @@
<jig>Standards JIG</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>JEP-0004</spec>
<spec>JEP-0030</spec>
<spec>JEP-0068</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0068</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -43,10 +43,10 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Developers periodically wonder why &jep0030; does not include more bits of information. For example, why does the &lt;identity/&gt; element not include a 'description' attribute, and can we add one now? The answer is: well, it just doesn't, and at this point it's too late to make further changes (since JEP-0030 is Final). So the best approach is to specify a well-defined extension mechanism.</p>
<p>Let us consider an example. A &jep0045; room might want to include additional information in its service discovery results, such as the full room description, the current discussion topic (room subject), the number of occupants in the room, and the JID of the room owner.</p>
<p>Adding one new attribute to the service discovery schema (even if that were an option) would not solve the problem, since a MUC service might want to provide certain bits of information, whereas a &jep0060; service might want to provide other bits.</p>
<p>A better solution would be to include extended information qualified by a namespace that provides a way to flexibly define structured data formats. Thankfully, we already possess such a protocol: &jep0004;. In addition, we possess a way to define common fields used in data forms: &jep0068;. Using these building blocks, we can define some best practices for extending service discovery results.</p>
<p>Developers periodically wonder why &xep0030; does not include more bits of information. For example, why does the &lt;identity/&gt; element not include a 'description' attribute, and can we add one now? The answer is: well, it just doesn't, and at this point it's too late to make further changes (since XEP-0030 is Final). So the best approach is to specify a well-defined extension mechanism.</p>
<p>Let us consider an example. A &xep0045; room might want to include additional information in its service discovery results, such as the full room description, the current discussion topic (room subject), the number of occupants in the room, and the JID of the room owner.</p>
<p>Adding one new attribute to the service discovery schema (even if that were an option) would not solve the problem, since a MUC service might want to provide certain bits of information, whereas a &xep0060; service might want to provide other bits.</p>
<p>A better solution would be to include extended information qualified by a namespace that provides a way to flexibly define structured data formats. Thankfully, we already possess such a protocol: &xep0004;. In addition, we possess a way to define common fields used in data forms: &xep0068;. Using these building blocks, we can define some best practices for extending service discovery results.</p>
</section1>
<section1 topic='Recommendations' anchor='recommendations'>
<p>If an entity desires to provide extended information about itself in an IQ results stanza within the context of the <cite>Service Discovery</cite> protocol, it SHOULD do so by including each bit of information as the XML character data of the &lt;value/&gt; child of a distinct &lt;field/&gt; element, with the entire set of fields contained within an &lt;x/&gt; element of type "result" qualified by the 'jabber:x:data' namespace; this &lt;x/&gt; element SHOULD be a child of the &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#info' namespace. Thus the IQ result SHOULD be of the following form:</p>
@ -63,7 +63,7 @@
</query>
</iq>]]></code>
<p>Note: A &lt;field/&gt; element MAY contain more than one &lt;value/&gt; child if appropriate.</p>
<p>If the data fields are to be used in the context of a protocol approved by the Jabber Software Foundation, they SHOULD be described in the relevant Jabber Enhancement Proposal and registered in accordance with the rules defined in JEP-0068, resulting in the inclusion of a &lt;field/&gt; element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".</p>
<p>If the data fields are to be used in the context of a protocol approved by the Jabber Software Foundation, they SHOULD be described in the relevant Jabber Enhancement Proposal and registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a &lt;field/&gt; element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".</p>
<p>An entity MUST NOT supply extended information about associated children communicated via the 'http://jabber.org/protocol/disco#items' namespace, since a core principle of <cite>Service Discovery</cite> is that an entity must define its own identity only and must not define the identity of any children associated with the entity.</p>
</section1>
<section1 topic='Examples' anchor='examples'>
@ -156,15 +156,15 @@
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>In general, the Jabber Software Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the Jabber Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.</p>
<p>In general, the Jabber Software Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Applications SHOULD ensure that information disclosed in a disco extension is appropriate for discovery by any entity on the network.</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'>
<p>This JEP requires no interaction with the &REGISTRAR;; however, JEPs following the best practices defined herein may register FORM_TYPEs and field values with the Jabber Registrar.</p>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the &REGISTRAR;; however, specifications following the best practices defined herein may register FORM_TYPEs and field values with the XMPP Registrar.</p>
</section1>
</jep>
</xep>

42
xep-0129.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>WebDAV File Transfers</title>
<abstract>This JEP specifies best practices for completing Jabber file transfers using WebDAV.</abstract>
<abstract>This document specifies best practices for completing Jabber file transfers using WebDAV.</abstract>
&LEGALNOTICE;
<number>0129</number>
<status>Deferred</status>
@ -16,9 +16,9 @@
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 2518</spec>
<spec>JEP-0030</spec>
<spec>JEP-0066</spec>
<spec>JEP-0070</spec>
<spec>XEP-0030</spec>
<spec>XEP-0066</spec>
<spec>XEP-0070</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -39,11 +39,11 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&jep0096; defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in &rfc2518;.</p>
<p>The use case in which the recipient is offline is the main driver behind this JEP. Another WebDAV use case presents itself in environments that use, or even require, WebDAV for file transfers using other protocols (e.g., files attached to email messages). The usual rationale for such deployments is virus-checking: the file is put onto the WebDAV server (either by an end-user or a script that, for example, strips attached files off email messages) and then checked for viruses; only after the virus check successfully completes is the recipient allowed to retrieve the file. A further benefit of such deployments is that it enables the sender to provide the file to multiple recipients. Thus the approach defined herein provides the added benefit of being usable in generic WebDAV environments as well.</p>
<p>&xep0096; defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in &rfc2518;.</p>
<p>The use case in which the recipient is offline is the main driver behind this document. Another WebDAV use case presents itself in environments that use, or even require, WebDAV for file transfers using other protocols (e.g., files attached to email messages). The usual rationale for such deployments is virus-checking: the file is put onto the WebDAV server (either by an end-user or a script that, for example, strips attached files off email messages) and then checked for viruses; only after the virus check successfully completes is the recipient allowed to retrieve the file. A further benefit of such deployments is that it enables the sender to provide the file to multiple recipients. Thus the approach defined herein provides the added benefit of being usable in generic WebDAV environments as well.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This JEP addresses the following requirements:</p>
<p>This document addresses the following requirements:</p>
<ol>
<li>Enable file transfers when recipient is offline.</li>
<li>Use WebDAV for file puts and gets.</li>
@ -51,11 +51,11 @@
</section1>
<section1 topic='Terminology' anchor='terms'>
<section2 topic='HTTP Terms' anchor='terms-http'>
<p>This JEP inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.</p>
<p>This document inherits terms from RFC 2518, &rfc2616;, and &rfc2617;.</p>
</section2>
</section1>
<section1 topic='Discovery' anchor='disco'>
<p>In order to discover a WebDAV server that supports this protocol, a client SHOULD use &jep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://jabber.org/protocol/webdav-filexfer". An example of the discovery flow is shown below.</p>
<p>In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://jabber.org/protocol/webdav-filexfer". An example of the discovery flow is shown below.</p>
<example caption='Client Discovers Services'><![CDATA[
<iq from='romeo@shakespeare.lit/home'
id='disco1'
@ -103,7 +103,7 @@
HEAD /uniqueurl HTTP/1.1
Host: files.shakespeare.lit
]]></code>
<p>Because the WebDAV server supports &jep0070;, the initial request fails (since the user did not provide Jabber authentication).</p>
<p>Because the WebDAV server supports &xep0070;, the initial request fails (since the user did not provide Jabber authentication).</p>
<code><![CDATA[
HTTP/1.1 401 Unauthorized
WWW-Authenticate: x-xmpp-auth realm=xmpp
@ -114,7 +114,7 @@
Host: files.shakespeare.lit
Authorization: x-xmpp-auth jid=[base64 encoded jid]
]]></code>
<p>Upon receipt of the HEAD request, the server then proceeds to verify the request using the x-xmpp-auth mechanism defined in JEP-0070. If the verification successfully completed, the server MAY cache further operations on this particular URL for the duration of the HTTP connection. It is recommended that clients keep the HTTP connection open, in accordance with HTTP/1.1 semantics.</p>
<p>Upon receipt of the HEAD request, the server then proceeds to verify the request using the x-xmpp-auth mechanism defined in XEP-0070. If the verification successfully completed, the server MAY cache further operations on this particular URL for the duration of the HTTP connection. It is recommended that clients keep the HTTP connection open, in accordance with HTTP/1.1 semantics.</p>
<p>In the "happy" path, the server responds that the requested URL was not found.</p>
<code><![CDATA[
@ -179,7 +179,7 @@
</response>
</multistatus>
]]></code>
<p>Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using &jep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &jep0033; protocol.)</p>
<p>Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using &xep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)</p>
<code><![CDATA[
<message to='multicast.jabber.org'>
<addresses xmlns='http://jabber.org/protocol/address'>
@ -198,7 +198,7 @@
Host: files.shakespeare.lit
Authorization: xmpp-auth (base64 encoded JID; juliet@capulet.com)
]]></code>
<p>The server then checks to ensure that the provided JID is on the jidlist property, and then authorizes the user via JEP-0070; if a JID not on the jidlist attempts to access the file, the server MUST return an HTTP 403 (Forbidden) error. On completion, the server then allows the file to be retrieved.</p>
<p>The server then checks to ensure that the provided JID is on the jidlist property, and then authorizes the user via XEP-0070; if a JID not on the jidlist attempts to access the file, the server MUST return an HTTP 403 (Forbidden) error. On completion, the server then allows the file to be retrieved.</p>
<code><![CDATA[
HTTP/1.1 200 OK
Date: Thu, 18 Dec 2003 18:00:00 GMT
@ -209,12 +209,12 @@
]]></code>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>See <strong>RFC 2518</strong>, <strong>XMPP Core</strong>, and <strong>JEP-0070</strong> for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.</p>
<p>See <strong>RFC 2518</strong>, <strong>XMPP Core</strong>, and <strong>XEP-0070</strong> for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.</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'>
<p>Upon advancement of this JEP to a status of Active, the &REGISTRAR; shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.</p>
<p>Upon advancement of this document to a status of Active, the &REGISTRAR; shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.</p>
</section1>
</jep>
</xep>