From d1178200c5756c2b257f8972f9700a97d87e2fa7 Mon Sep 17 00:00:00 2001
From: Kurt Zeilenga <kurt.zeilenga@isode.com>
Date: Mon, 27 Jul 2009 18:00:51 +0000
Subject: [PATCH] Remove <label/>/<equivalentlabel/> type= attribute. Clarify
 label catalog discovery. Clarify syntax of selector= attribute.

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3338 4b5297f7-1745-476d-ba37-a9c6900126ab
---
 xep-0258.xml | 51 +++++++++++++++++++++++++++++++++++----------------
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/xep-0258.xml b/xep-0258.xml
index 74c16be1..20427ef7 100644
--- a/xep-0258.xml
+++ b/xep-0258.xml
@@ -2,6 +2,7 @@
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
   <!ENTITY % ents SYSTEM 'xep.ent'>
   <!ENTITY LABEL "&lt;label/&gt;">
+  <!ENTITY CATALOG "&lt;catalog/&gt;">
   <!ENTITY SECURITYLABEL "&lt;securitylabel/&gt;">
   <!ENTITY DISPLAYMARKING "&lt;displaymarking/&gt;">
   <!ENTITY EQUIVALENTLABEL "&lt;equivalentlabel/&gt;">
@@ -35,6 +36,12 @@
     <email>Kurt.Zeilenga@Isode.COM</email>
     <jid>Kurt.Zeilenga@Isode.COM</jid>
   </author>
+  <revision>
+    <version>0.5 (draft)</version>
+    <date>2009-07-27</date>
+    <initials>kdz</initials>
+    <remark><p>Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery.  Clarify syntax of selector= attribute.</p></remark>
+  </revision>
   <revision>
     <version>0.4</version>
     <date>2009-07-23</date>
@@ -186,17 +193,16 @@
   <p>The security label metadata is carried in an &SECURITYLABEL; element.
      The &SECURITYLABEL; element which contains one and only one &LABEL; element,
      zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p>
-  <p>The &LABEL; contains the primary security label.  It is commonly issued by the
-     sender under the security policy of that they and their home server operating under.
-     Each &EQUIVALENTLABEL; holds equivalent security labels under other policies.
-     This element might be used when a recepient is known to hold a clearance under a
-     different policy than the sender.</p>
-  <p>The &LABEL; and &EQUIVALENTLABEL; elements each require a <tt>type=</tt> attribute.
-     The <tt>type=</tt> attribute indicates the type and encoding of the element's value.
-     The attribute <tt>type=</tt> value '<tt>ESS</tt>' indicates the label is the
-     base64, as specified in &rfc4648;, encoding of the &BER; encoding of the &ASN.1;
-         <tt>eSSSecurityLabel</tt> type as specified in &rfc2634;.
-     Additional types may be registered (see 'XMPP Registrar Considerations').</p>
+  <p>The &LABEL; provides the primary security label.  It is commonly issued
+     by the sender under the security policy of that they and their home
+     server operating under.  The &LABEL; contains either a single element
+     representing the primary security label or is empty to indicate use of
+     a default.</p>
+  <p>Each &EQUIVALENTLABEL; represents an equivalent security label under
+     other policies.  Each &EQUIVALENTLABEL; contains a single element
+     representing the equivalent label.  This element might be used when
+     a recepient is known to hold a clearance under a different policy
+     than the sender.</p>
   <p>The &DISPLAYMARKING; element contains a display string for use by
      implementations which are unable to utilize the applicable security policy
      to generate display markings.  The element may optionally contain two
@@ -208,7 +214,19 @@
 </section1>
 
 <section1 topic='Label Catalog Discovery' anchor='label-catalog'>
-    <p>It is RECOMMENDED the server publish a catalogs of security label
+    <p>A client can request a catalog for a particular JID by sending
+       an catalog discovery request to the client's server.  Where the JID
+       is hosted by some other server, the client's server is expected to
+       produce a suitable catalog (or fail the request).  The client's server
+       may, as needed, query catalogs from other servers in order to
+       fulfill the client's request.</p>
+    <p>While this specificatin does not preclude a client from directing
+       a catalog request elsewhere, it is noted that catalog returned by
+       a party other than its server may not be directly useable by the
+       client.  For instance, the client's server might require a particular
+       only-locally-known label be used in messages to a particular remote
+       jid.</p>
+    <p>It is RECOMMENDED the server publish catalogs of security label
        for use by clients.</p>
     <p>Each catalog provided should only contain labels for which the client
        is allowed to use (based upon the user's authorization) in a particular
@@ -228,14 +246,15 @@
        The following pair of examples illustrates this feature discovery.</p>
     <p>Each item in the catalog may contain a selector attribute.  The
        value of this attribute represents the item's placement in a
-       hierarchical organization of the items.  The form is:
+       hierarchical organization of the items.  The value of the selector
+       attribute conforms to the selector-value ABNF production:
 <blockquote>
 <![CDATA[
-<label>"|"]*<label>
+selector-value = (<item>"|")*<item>
 ]]>
 </blockquote>
     </p>
-    <p>where &lt;label&gt; is a sequence of characters not including "|".</p>.
+    <p>where &lt;item&gt; is a sequence of characters not including "|".</p>
     <p>A value of "X|Y|Z" indicates that this item is "Z" in the
        the "Y" subset of the "X" subset of items.  This information may
        be used, for instance, in generating label selection menus in
@@ -262,7 +281,7 @@
 </iq>
   ]]></example>
   
-    <p>The following example pair illustrates catalog discovery.</p>
+    <p>The following example pair illustrates catalog discovery.  Note that client directs the &IQ; to its server regardless of which catalog it requests (via the to= attribute of in &CATALOG; element).</p>
 
     <example caption="Label Catalog request"><![CDATA[
 <iq type='get' id='cat1'>