1.13rc7

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3628 4b5297f7-1745-476d-ba37-a9c6900126ab
2024-12-22 07:38:52 -05:00 · 2009-11-17 18:52:23 +00:00 · 2009-11-17 18:52:23 +00:00 · 68e2a6c43a
commit 68e2a6c43a
parent 982035127b
1 changed files with 50 additions and 14 deletions
--- a/xep-0060.xml
+++ b/xep-0060.xml
@ -14,6 +14,7 @@
  &LEGALNOTICE;
  <number>0060</number>
  <status>Draft</status>
+  <interim/>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <dependencies>
@ -50,8 +51,8 @@
  &ralphm;

  <revision>
-    <version>1.13rc6</version>
-    <date>in progress, 2009-10-01</date>
+    <version>1.13rc7</version>
+    <date>in progress, 2009-11-17</date>
    <initials>psa</initials>
    <remark>
      <ul>
@ -76,6 +77,7 @@
        <li>Added optional support for delivery of notifications via XMPP IQ stanzas.</li>
        <li>Removed the notion of batch publishing because it makes information coherence and atom handling excessively difficult.</li>
        <li>Added error handling for too-many-subscriptions to help prevent a certain denial of service attack.</li>
+        <li>Added process for retrieving default subscription configuration options for leaf nodes, by omitting the 'node' attribute on the &lt;default/&gt; element (also added the &lt;default/&gt; element to the schema for the http://jabber.org/protocol/pubsub namespace, since it was missing).</li>
      </ul>
    </remark>
  </revision>
@ -381,7 +383,7 @@ And by opposing end them?
  </pubsub>
 </iq>
    ]]></example>
-    <p>So that is the "pub" part of publish-subscribe.</p>
+    <p>So that is the "pub" part of pubsub.</p>
    <p>Now the pubsub service notifies all the subscribers about the new blog entry:</p>
    <example caption='Service Notifies Subscribers'><![CDATA[
 <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
@ -455,7 +457,7 @@ And by opposing end them?
    <di><dt>Owner</dt><dd>The manager of a node, of which there may be more than one; often but not necessarily the node creator.</dd></di>
    <di><dt>Payload</dt><dd>The full data associated with an event rather than just the event notification itself.</dd></di>
    <di><dt>Open Access Model</dt><dd>A node access model under which any entity may subscribe and retrieve items without approval.</dd></di>
-    <di><dt>Paylod</dt><dd>The XML data that is contained within the &lt;item/&gt; element of a publication request or a notification event. A given payload is defined by an XML namespace and associated schema. A document that defines a payload format SHOULD specify whether the payload can be used only for a NodeID whose value is the same as the XML namespace, or whether the payload can be used for any NodeID. Such a document also SHOULD specify whether it is suggested that node at which such payloads are published are best configured as <link url='#impl-singleton'>Singleton Nodes</link>.</dd></di>
+    <di><dt>Payload</dt><dd>The XML data that is contained within the &lt;item/&gt; element of a publication request or a notification event. A given payload is defined by an XML namespace and associated schema. A document that defines a payload format SHOULD specify whether the payload can be used only for a NodeID whose value is the same as the XML namespace, or whether the payload can be used for any NodeID. Such a document also SHOULD specify whether it is suggested that node at which such payloads are published are best configured as <link url='#impl-singleton'>Singleton Nodes</link>.</dd></di>
    <di><dt>Personal Eventing</dt><dd>A simplified subset of Publish-Subscribe for use in the context of instant messaging and presence applications, whereby each IM user's JID is a virtual pubsub service; for details, see &xep0163;.</dd></di>
    <di><dt>Presence Access Model</dt><dd>A node access model under which any entity that is subscribed to the owner's presence with a subscription of type "from" or "both" (see &rfc3921;) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems.</dd></di>
    <di><dt>Publisher</dt><dd>An entity that is allowed to publish items to a node.</dd></di>
@ -474,7 +476,7 @@ And by opposing end them?
  <ul>
    <li>An entity MUST be able to publish events to a service such that all subscribers to a node receive notification of the event. See <link url='#publisher-publish'>Publish an Item to a Node</link>.</li>
    <li>An entity MUST be able to subscribe to a node (or be informed that subscription is not allowed). See <link url='#subscriber-subscribe'>Subscribe to a Node</link>.</li>
-    <li>An entity MUST be allowed to be affiliated with a node. Allowable affiliations are owner, publisher, none, and outcast. Implementations MUST support affiliations of owner and none, and MAY support affiliations of outcast, publisher, and publish-only. See <link url='#affiliations'>Affiliations</link>.</li>
+    <li>An entity MUST be allowed to be affiliated with a node. Allowable affiliations are member, none, outcast, owner, publish-only, and publisher. Implementations MUST support affiliations of none and owner, and MAY support affiliations of member, outcast, publisher, and publish-only. See <link url='#affiliations'>Affiliations</link>.</li>
    <li>An entity MUST be allowed to query the pubsub service (or a specific node) to determine what optional features of this specification the service (or node) implements. This query MUST use the Service Discovery (disco#info) protocol. See <link url='#entity-info'>Discover Node Information</link>.</li>
  </ul>

@ -884,7 +886,7 @@ And by opposing end them?
 </iq>
    ]]></example>
  </section2>
-  <section2 topic='Discover Node Meta-Data' anchor='entity-metadata'>
+  <section2 topic='Discover Node Metadata' anchor='entity-metadata'>
    <p>The "disco#info" result MAY include detailed meta-data about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#meta-data" in accordance with &xep0068;. If meta-data is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.</p>
    <example caption='Entity queries a node for information'><![CDATA[
 <iq type='get'
@ -945,8 +947,8 @@ And by opposing end them?
    <p>Note: Node meta-data can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node meta-data SHOULD be provided as fields in the node configuration form.</p>
    <p>Note: The pubsub#language field SHOULD be list-single so that the pubsub service can present an appropriate list of languages and language codes.</p>
    <p>Much of the meta-data provided about a node maps directly to selected &DUBLINCORE; meta-data attributes; specifically:</p>
-    <table caption='Dublin Core Meta-Data Mapping'>
-      <tr><th>Pubsub Field</th><th>Dublin Core Meta-Data Attribute</th></tr>
+    <table caption='Dublin Core Metadata Mapping'>
+      <tr><th>Pubsub Field</th><th>Dublin Core Metadata Attribute</th></tr>
      <tr><td>pubsub#creation_date</td><td>Date <note>The value SHOULD be a DateTime as defined in <cite>XEP-0082</cite>, and MUST conform to one of the profiles defined therein.</note></td></tr>
      <tr><td>pubsub#creator</td><td>Creator</td></tr>
      <tr><td>pubsub#description</td><td>Description</td></tr>
@ -1078,7 +1080,7 @@ And by opposing end them?
 </iq>
    ]]></example>
    <p>If the service returns a list of affiliations, it MUST return all affiliations for all JIDs that match the bare JID &BAREJID; portion of the 'from' attribute on the request.</p>
-    <p>For each affiliation, an &lt;affiliation/&gt; element is returned containing the NodeID and the affiliation state (owner, publisher, or outcast).</p>
+    <p>For each affiliation, an &lt;affiliation/&gt; element is returned containing the NodeID and the affiliation state (owner, publisher, publish-only, member, or outcast).</p>
    <example caption='Service replies with all current affiliations'><![CDATA[
 <iq type='result'
    from='pubsub.shakespeare.lit'
@ -1897,9 +1899,9 @@ And by opposing end them?
    </section3>
  </section2>
  <section2 topic='Request Default Subscription Configuration Options' anchor='subscribe-default'>
-    <p>An entity may want to request information about the default subscription configuration. Support for this feature is OPTIONAL.</p>
+    <p>An entity might want to request information about the default subscription configuration. Support for this feature is OPTIONAL.</p>
    <section3 topic='Request' anchor='subscriber-default-request'>
-      <p>To get the default subscription options, the entity MUST send an empty &lt;default/&gt; element to the node (not the service); in response, the node SHOULD return the default subscription options.</p>
+      <p>To get the default subscription options for a node, the entity MUST send an empty &lt;default/&gt; element to the node; in response, the node SHOULD return the default subscription options.</p>
      <example caption='Entity requests default subscription configuration options'><![CDATA[
 <iq type='get'
    from='francisco@denmark.lit/barracks'
@ -1911,6 +1913,18 @@ And by opposing end them?
 </iq>
      ]]></example>
      <p>Note: Here the namespace is 'http://jabber.org/protocol/pubsub' (not 'http://jabber.org/protocol/pubsub#owner' as for retrieval of the default node configuration options).</p>
+      <p>The service itself MAY also have default subscription configuration options. To get the default subscription configuration options all (leaf) nodes at a service, the entity MUST send an empty &lt;default/&gt; element but not specifiy a node; in response, the service SHOULD return the default subscription options.</p>
+      <example caption='Entity requests default subscription configuration options'><![CDATA[
+<iq type='get'
+    from='francisco@denmark.lit/barracks'
+    to='pubsub.shakespeare.lit'
+    id='def2'>
+  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
+    <default/>
+  </pubsub>
+</iq>
+      ]]></example>
+      <p>The process for retrieving the default subscription configuration options for collection nodes is described in <cite>XEP-0248</cite>.</p>
    </section3>
    <section3 topic='Success Case' anchor='subscriber-default-success'>
      <p>If no error occurs, the node MUST return the default subscription configuration options.</p>
@ -3566,6 +3580,7 @@ And by opposing end them?
    to='hamlet@denmark.lit/elsinore'
    id='config2'/>
        ]]></example>
+        <p>Note: If the node type was changed from leaf to collection and there are items associated with the node, the service MUST purge the node of all items (with or without notification).</p>
      </section4>
      <section4 topic='Failure' anchor='owner-configure-process-failure'>
        <p>If the requested node configuration change cannot be processed (e.g., because the node owner has attempted to change the configuration so that there are no node owners), the service MUST return a &notacceptable; error to the owner.</p>
@ -4432,7 +4447,7 @@ And by opposing end them?
        ]]></example>
      </section4>
      <section4 topic='Success Case' anchor='owner-affiliations-retrieve-success'>
-        <p>If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "publisher", "publish-only", or "outcast" (it MUST NOT return entities whose affiliation is "none").</p>
+        <p>If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "member", "publisher", "publish-only", or "outcast" (it MUST NOT return entities whose affiliation is "none").</p>
        <example caption='Service returns list of affiliated entities'><![CDATA[
 <iq type='result'
    from='pubsub.shakespeare.lit'
@ -5907,7 +5922,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
      <li>Authorization of subscriptions using the 'http://jabber.org/protocol/pubsub#subscribe_authorization' namespace.</li>
      <li>Configuration of subscription options using the 'http://jabber.org/protocol/pubsub#subscribe_options' namespace.</li>
      <li>Configuration of a node using the 'http://jabber.org/protocol/pubsub#node_config' namespace.</li>
-      <li>Setting of meta-data information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.</li>
+      <li>Setting of metadata information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.</li>
    </ol>
    <p>The registry submissions associated with these namespaces are defined below.</p>
    <p>Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of <cite>XEP-0068</cite>, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.</p>
@ -6012,7 +6027,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
 <form_type>
  <name>http://jabber.org/protocol/pubsub#meta-data</name>
  <doc>XEP-0060</doc>
-  <desc>Forms enabling setting of meta-data information about pubsub nodes</desc>
+  <desc>Forms enabling setting of metadata information about pubsub nodes</desc>
  <field var='pubsub#contact'
         type='jid-multi'
         label='The JIDs of those to contact with questions'/>
@ -6381,6 +6396,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
        </xs:sequence>
        <xs:choice minOccurs='0'>
          <xs:element ref='affiliations'/>
+          <xs:element ref='default'/>
          <xs:element ref='items'/>
          <xs:element ref='publish'/>
          <xs:element ref='retract'/>
@ -6440,6 +6456,26 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
    </xs:complexType>
  </xs:element>

+  <xs:element name='default'>
+    <xs:complexType>
+      <xs:simpleContent>
+        <xs:extension base='empty'>
+          <xs:attribute name='node' type='xs:string' use='optional'/>
+          <xs:attribute name='type'
+                        use='optional'
+                        default='leaf'>
+            <xs:simpleType>
+              <xs:restriction base='xs:NCName'>
+                <xs:enumeration value='collection'/>
+                <xs:enumeration value='leaf'/>
+              </xs:restriction>
+            </xs:simpleType>
+          </xs:attribute>
+        </xs:extension>
+      </xs:simpleContent>
+    </xs:complexType>
+  </xs:element>
+
  <xs:element name='items'>
    <xs:complexType>
      <xs:sequence>