0.6

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1798 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0154.xml

@@ -25,8 +25,14 @@
     <spec>XEP-0054</spec>
   </supersedes>
   <supersededby/>
-  <shortname>TO BE ASSIGNED</shortname>
+  <shortname>TO-BE-ASSIGNED</shortname>
   &stpeter;
+  <revision>
+    <version>0.6</version>
+    <date>2008-04-18</date>
+    <initials>psa</initials>
+    <remark><p>Updated to reflect stable PEP protocol; added OpenID field; specified XML schema; changed namespace to conform to XMPP Registrar procedures.</p></remark>
+  </revision>
   <revision>
     <version>0.5</version>
     <date>2006-08-02</date>
@@ -124,7 +130,7 @@
     <ol>
       <li>
         <p><strong>IQ (request-and-response) semantics.</strong></p>
-        <p>In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace &NSNOTE;.</p>
+        <p>In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'urn:xmpp:tmp:profile' namespace &NSNOTE;.</p>
       </li>
       <li>
         <p><strong>Pubsub (publish-and-subscribe) semantics.</strong></p>
@@ -167,13 +173,13 @@
         </ol>
       </li>
     </ul>
-    <p>Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns' &NSNOTE;, in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the &REGISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
+    <p>Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile' &NSNOTE;, in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the &REGISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
     <p>The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:</p>
     <example caption='A Basic Example'><![CDATA[
-<profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+<profile xmlns='urn:xmpp:tmp:profile'>
   <x xmlns='jabber:x:data' type='result'>
     <field var='FORM_TYPE' type='hidden'>
-      <value>http://www.xmpp.org/extensions/xep-0154.html#ns</value>
+      <value>urn:xmpp:tmp:profile</value>
     </field>
     <field var='common_name'>
       <value>Peter Saint-Andre</value>
@@ -188,7 +194,7 @@
   </x>
 </profile>
     ]]></example>
-      <p>By specifying that all fields are scoped by a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.</p>
+      <p>By specifying that all fields are scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'urn:xmpp:tmp:profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.</p>
       <p>However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (<cite>RFC 2426</cite>) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.</p>
       <p>In order to address most (if not all) of the pieces of information described in existing profile specifications, this document defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
   </section2>
@@ -198,10 +204,10 @@
     <p>In order to publish a full profile, an entity sends an IQ-set to its server with a child element of &lt;profile/&gt; containing the full profile information.</p>
     <example caption='Entity publishes full profile'><![CDATA[
 <iq type='set' id='setfull'>
-  <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+  <profile xmlns='urn:xmpp:tmp:profile'>
     <x xmlns='jabber:x:data' type='submit'>
       <field var='FORM_TYPE' type='hidden'>
-        <value>http://www.xmpp.org/extensions/xep-0154.html#ns</value>
+        <value>urn:xmpp:tmp:profile</value>
       </field>
       <field var='nickname'>
         <value>Hamlet</value>
@@ -226,12 +232,12 @@
     <p>Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.</p>
   </section2>
   <section2 topic='Updating One or More Profile Fields' anchor='producer-pub'>
-    <p>In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://www.xmpp.org/extensions/xep-0154.html#ns" at its server using the PEP subset of the publish-subscribe extension, as specified in <cite>XEP-0163</cite>.</p>
+    <p>In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "urn:xmpp:tmp:profile" at its server using the PEP subset of the publish-subscribe extension, as specified in <cite>XEP-0163</cite>.</p>
     <example caption='Account owner publishes profile field(s)'><![CDATA[
 <iq type='set' id='pub1'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <publish node='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+    <publish node='urn:xmpp:tmp:profile'>
-      <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+      <profile xmlns='urn:xmpp:tmp:profile'>
         <x xmlns='jabber:x:data' type='result'>
           <field var='weblog'>
             <value>http://www.denmark.lit/blogs/princely_musings</value>
@@ -246,9 +252,9 @@
     <example caption='Server generates notifications'><![CDATA[
 <message to='francisco@denmark.lit' from='hamlet@denmark.lit/elsinore' type='headline' id='foo'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
-    <items node='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+    <items node='urn:xmpp:tmp:profile'>
       <item>
-        <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+        <profile xmlns='urn:xmpp:tmp:profile'>
           <x xmlns='jabber:x:data' type='result'>
             <field var='weblog'>
               <value>http://www.denmark.lit/blogs/princely_musings</value>
@@ -270,7 +276,7 @@
 </section1>
 <section1 topic='Consumer Use Cases' anchor='consumer'>
   <section2 topic='Discovering Support' anchor='consumer-disco'>
-    <p>If an entity can provide profile data directly using the standalone 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:</p>
+    <p>If an entity can provide profile data directly using the standalone 'urn:xmpp:tmp:profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:</p>
     <example caption='A request for service discovery information'><![CDATA[
 <iq type='get'
     from='bard@shakespeare.lit/globe'
@@ -286,22 +292,23 @@
     id='disco1'>
   <query xmlns='http://jabber.org/protocol/disco#info'>
     <identity category='account' type='registered'/>
+    <identity category='pubsub' type='pep'/>
     ...
-    <feature var='http://www.xmpp.org/extensions/xep-0154.html#ns'/>
+    <feature var='urn:xmpp:tmp:profile'/>
     ...
   </query>
 </iq>
     ]]></example>
-    <p>Note: Because the foregoing request was sent to the bare JID &lt;hamlet@denmark.lit&gt;, the response is provided by the &lt;denmark.lit&gt; server on behalf of the registered account. The answer indicates that the server can also provide profile data on behalf of the registered account.</p>
+    <p>Note: Because the foregoing request was sent to the bare JID &lt;hamlet@denmark.lit&gt;, the response is provided by the &lt;denmark.lit&gt; server on behalf of the registered account. The answer indicates that the server can provide profile data on behalf of the registered account and that it supports the personal eventing profile of XMPP Publish-Subscribe.</p>
   </section2>
   <section2 topic='Requesting Full Profile' anchor='consumer-full'>
-    <p>In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty &lt;profile/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace. In this example, the request is sent to a server:</p>
+    <p>In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty &lt;profile/&gt; element qualified by the 'urn:xmpp:tmp:profile' namespace. In this example, the request is sent to a server, not a user (any XMPP entity can have a profile, including servers, gateways, &xep0045; rooms, and the like):</p>
     <example caption='A request for profile data'><![CDATA[
 <iq type='get'
     from='hamlet@denmark.lit/elsinore'
     to='shakespeare.lit'
     id='iq1'>
-  <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'/>
+  <profile xmlns='urn:xmpp:tmp:profile'/>
 </iq>
     ]]></example>
     <p>The server then replies:</p>
@@ -310,10 +317,10 @@
     from='shakespeare.lit'
     to='hamlet@denmark.lit/elsinore'
     id='iq1'>
-  <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+  <profile xmlns='urn:xmpp:tmp:profile'>
     <x xmlns='jabber:x:data' type='result'>
       <field var='FORM_TYPE' type='hidden'>
-        <value>http://www.xmpp.org/extensions/xep-0154.html#ns</value>
+        <value>urn:xmpp:tmp:profile</value>
       </field>
       <field var='common_name'>
         <value>shakespeare.lit IM server</value>
@@ -364,7 +371,7 @@
     from='bard@shakespeare.lit/globe'
     to='hamlet@denmark.lit'
     id='iq2'>
-  <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'/>
+  <profile xmlns='urn:xmpp:tmp:profile'/>
 </iq>
     ]]></example>
     <p>If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a whitelist of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:</p>
@@ -373,7 +380,7 @@
     from='hamlet@denmark.lit'
     to='bard@shakespeare.lit/globe'
     id='iq2'>
-  <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'/>
+  <profile xmlns='urn:xmpp:tmp:profile'/>
   <error code='503' type='cancel'>
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
@@ -386,10 +393,10 @@
     from='hamlet@denmark.lit'
     to='bard@shakespeare.lit/globe'
     id='iq2'>
-  <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+  <profile xmlns='urn:xmpp:tmp:profile'>
     <x xmlns='jabber:x:data' type='result'>
       <field var='FORM_TYPE' type='hidden'>
-        <value>http://www.xmpp.org/extensions/xep-0154.html#ns</value>
+        <value>urn:xmpp:tmp:profile</value>
       </field>
       <field var='nickname'>
         <value>Hamlet</value>
@@ -412,31 +419,13 @@
     ]]></example>
   </section2>
   <section2 topic='Receiving Profile Updates' anchor='consumer-sub'>
-    <p>In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID &LOCALBARE; and specify a node of "http://www.xmpp.org/extensions/xep-0154.html#ns":</p>
+    <p>In order to receive updated fields for a contact's profile, an entity shall encapsulate a feature of "urn:xmpp:tmp:profile+notify" in its &xep0115; data. If the contact's server supports the personal eventing profile of XMPP Publish-Subscribe as described in <cite>XEP-0163</cite>, the entity will receive notifications whenever the contact sends updated profile fields to the profile node:</p>
-    <example caption='Entity subscribes to profile node'><![CDATA[
-<iq type='set'
-    from='francisco@denmark.lit/barracks'
-    to='hamlet@denmark.lit'
-    id='sub1'>
-  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <subscribe node='http://www.xmpp.org/extensions/xep-0154.html#ns' jid='francisco@denmark.lit'/>
-  </pubsub>
-</iq>
-    ]]></example>
-    <p>If the server allows the subscription, it MUST return an IQ-result (see <cite>XEP-0163</cite> for error scenarios):</p>
-    <example caption='Server allows subscription'><![CDATA[
-<iq type='result'
-    from='hamlet@denmark.lit'
-    to='francisco@denmark.lit/barracks'
-    id='sub1'/>
-    ]]></example>
-    <p>When the contact sends updated fields to the profile node, the entity will receive notifications:</p>
     <example caption='Entity receives notification'><![CDATA[
 <message to='francisco@denmark.lit' from='hamlet@denmark.lit/elsinore' type='headline' id='foo'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
-    <items node='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+    <items node='urn:xmpp:tmp:profile'>
       <item>
-        <profile xmlns='http://www.xmpp.org/extensions/xep-0154.html#ns'>
+        <profile xmlns='urn:xmpp:tmp:profile'>
           <x xmlns='jabber:x:data' type='result'>
             <field var='weblog'>
               <value>http://www.denmark.lit/blogs/princely_musings</value>
@@ -448,7 +437,7 @@
   </event>
 </message>
     ]]></example>
-    <p>It is the responsibility of the receiving entity to correctly process the notification and update the contact's profile information accordingly.</p>
+    <p>It is the responsibility of the receiving entity to correctly process the notification and update the local representation of the contact's profile information.</p>
   </section2>
 </section1>
 <section1 topic='Data Representation' anchor='fields'>
@@ -1018,6 +1007,19 @@
       <example caption='Homepage URL'><![CDATA[
 <field var='homepage'>
   <value>http://www.saint-andre.com/</value>
+</field>
+      ]]></example>
+    </section3>
+    <section3 topic='OpenID' anchor='openid'>
+      <p>An OpenID is the value of a URI by which a person can sign onto multiple websites or other Internet services using a single identifier (see &lt;<link url='http://openid.net/'>http://openid.net/</link>&gt;).</p>
+      <p>The Data Forms field that represents an OpenID is "openid".</p>
+      <p>This field maps to:</p>
+      <ul>
+        <li>FOAF openid</li>
+      </ul>
+      <example caption='OpenID'><![CDATA[
+<field var='openid'>
+  <value>https://stpeter.startssl.com/</value>
 </field>
       ]]></example>
     </section3>
@@ -1923,25 +1925,35 @@ XhK8hFkPvXjudl7xAJ95+2fAHfmHheZJVaO8VaJiL54Tvw==
   <p>This document requires no interaction with &IANA;.</p>
 </section1>
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <section2 topic='Protocol Namespaces' anchor='ns'>
+    <p>Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:profile"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
+  </section2>
   <section2 topic='Field Standardization' anchor='registrar-formtype'>
     <p>To follow.</p>
-    <!--
-    <code caption='Registry Submission'><![CDATA[
-<form_type>
-  <name>http://www.xmpp.org/extensions/xep-0154.html#ns</name>
-  <doc>XEP-0154</doc>
-  <desc>Forms for entity profile data.</desc>
-  <field
-      var='given_name'
-      type='text-single'
-      label='Given (First) Name'/>
-  <field
-      var='family_name'
-      type='text-single'
-      label='Family (Last) Name'/>
-</form_type>
-    ]]></code>
-    -->
   </section2>
 </section1>
+<section1 topic='XML Schema' anchor='schema'>
+  <code><![CDATA[
+<?xml version='1.0' encoding='UTF-8'?>
+
+<xs:schema
+    xmlns:xs='http://www.w3.org/2001/XMLSchema'
+    targetNamespace='urn:xmpp:tmp:profile'
+    xmlns='urn:xmpp:tmp:profile'
+    elementFormDefault='qualified'>
+
+  <xs:import
+      namespace='jabber:x:data'
+      schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>
+
+  <xs:element name='profile'>
+    <xs:complexType>
+      <xs:sequence xmlns:data='jabber:x:data'>
+        <xs:element ref='data:x'/>
+      </xs:sequence>
+    </xs:complexType>
+
+</xs:schema>
+  ]]></code>
+</section1>
 </xep>