v0.9 editorial changes and add optional jid to catalog request.

xep-0258.xml

@@ -15,8 +15,8 @@
 <header>
   <title>Security Labels in XMPP</title>
   <abstract>This document describes the use of security labels in XMPP.  The document
-    specifies how security label metadata is carried in XMPP, when this metadata
+    specifies how security label meta-data is carried in XMPP, when this meta-data
-    should or should not be provided, and how the metadata is to be processed.</abstract>
+    should or should not be provided, and how the meta-data is to be processed.</abstract>
   &LEGALNOTICE;
   <number>0258</number>
   <status>Experimental</status>
@@ -36,6 +36,12 @@
     <email>Kurt.Zeilenga@Isode.COM</email>
     <jid>Kurt.Zeilenga@Isode.COM</jid>
   </author>
+  <revision>
+    <version>0.9</version>
+    <date>2011-09-15</date>
+    <initials>kdz</initials>
+    <remark><p>Add optional from attribute to catalog element for S2S requests. Make editorial changes.</p></remark>
+  </revision>
   <revision>
     <version>0.8</version>
     <date>2011-08-11</date>
@@ -46,7 +52,7 @@
     <version>0.7</version>
     <date>2011-03-08</date>
     <initials>kdz</initials>
-    <remark><p>Illustrate XEP 45 security label room configuration.  Make clarifications and minor editorial changes.</p></remark>
+    <remark><p>Illustrate XEP Multi-User Chat room security label configuration.  Make clarifications and minor editorial changes.</p></remark>
   </revision>
   <revision>
     <version>0.6</version>
@@ -106,7 +112,7 @@
      standardized formats for security labels, clearances, and security policy are
      generalized and do have application in non-government networks.</p>
   <p>This document describes the use of security labels in &xmpp;.  The document specifies
-     how security label metadata is carried in XMPP.  It standardizes a mechanism for
+     how security label meta-data is carried in XMPP.  It standardizes a mechanism for
      carrying ESS Security Labels in XMPP, as well as provides for use of other label
      formats.  ESS Security Labels are specified in &rfc2634;.  ESS Security Labels are
      commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c;
@@ -134,8 +140,8 @@
   ]]></example>
   <p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
   
-  <p>The document details when security label metadata should or should not be provided, and how
+  <p>The document details when security label meta-data should or should not be provided, and how
-     this metadata is to be processed.</p>
+     this meta-data is to be processed.</p>
 
   <p>This document does not provide:
      <ul>
@@ -188,7 +194,7 @@
 </section1>
 
 <section1 topic='Protocol' anchor='protocol'>
-  <p>An element, &SECURITYLABEL;, is defined to carry security label metadata.  This metadata
+  <p>An element, &SECURITYLABEL;, is defined to carry security label meta-data.  This meta-data
      includes a security label, zero or more equivalent security labels, and optionally display
      marking data.</p>
   <example caption="Labeled Message"><![CDATA[
@@ -239,7 +245,7 @@
        fulfill the client's request.</p>
     <p>While this specification 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
+       a party other than its server may not be directly usable 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>
@@ -259,7 +265,7 @@
        complete set of labels available for the use by the client in the
        context.</p>
     <blockquote>Note: the single catalog per context approach used here
-       is likely inadequate in enviroments where there are a large number
+       is likely inadequate in environments where there are a large number
        of labels in use.  It is expected that a more sophisticated approach
        will be introduced in a subsequent revision of this
        specification.</blockquote>
@@ -308,7 +314,11 @@ selector-value = (<item>"|")*<item>
 </iq>
   ]]></example>
   
-    <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>
+
+<p>The following example pair illustrates catalog discovery.  The
+client directs the &IQ; to its server regardless of which catalog
+it requests via the to= attribute of in &CATALOG; element.  The
+client SHOULD NOT provide a from= attribute in the &CATALOG; element.</p>
 
     <example caption="Label Catalog request"><![CDATA[
 <iq to='example.com' type='get' id='cat1'>
@@ -354,6 +364,15 @@ selector-value = (<item>"|")*<item>
 </iq>
   ]]></example>
 
+<p>
+Where the server needs to obtain a catalog from another server in order
+to respond to its client, it can send an &IQ; to that server requesting
+that catalog.  The requesting server provides the bare JID of the
+requesting user in the from= attribute in the &CATALOG; element when
+it desires a catalog to be prepared specifically for the user.
+Otherwise the from= attribute in the &CATALOG; element is absent.
+</p>
+
 </section1>
 
 <section1 topic='Use in XMPP' anchor='xmpp-use'>
@@ -389,7 +408,7 @@ selector-value = (<item>"|")*<item>
      absent.</p>
   <p>A client which receives a stanza with &SECURITYLABEL; element is to promiently
      display the &DISPLAYMARKING; value.   A policy-aware may alternatively
-     promiently display the marking for the &LABEL; prescribed by the governing
+     prominently display the marking for the &LABEL; prescribed by the governing
      policy.</p>
   <p>Each server is expected to make a number of sensitivity-based authorization
      decisions. Each decision is made by evaluating an Access Control Decision
@@ -435,13 +454,13 @@ selector-value = (<item>"|")*<item>
         <p>Clients SHOULD discover label feature and information on a per room basis.</p>
     </section3>
     <section3 topic='Sending Messages' anchor='muc-send'>
-        <p>Sending groupchat messages is similiar to sending normal messages, however
+        <p>Sending groupchat messages is similar to sending normal messages, however
            their are a few differences.</p>
         <p>Groupchat messages are addressed to the room.  The room clearance must
            be suitable for the message label, else it should be rejected.</p>
         <p>The room's clearance may allow a variety of labels to be used.  Not all
-           partipants may be cleared for all labels allowed in the room.  The server
+           participants may be cleared for all labels allowed in the room.  The server
-           MUST only deliver messages to partipants for which they are cleared to
+           MUST only deliver messages to participants for which they are cleared to
            receive.</p>
     </section3>
     <section3 topic='Private Messages' anchor='muc-private'>
@@ -636,7 +655,7 @@ And by opposing end them?
   <p>This document is all about authorization, a key aspect of security.  Hence,
      security considerations are discussed through this document.</p>
   <p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject
-     to any sensitity-based authorization decisions, and may be forwarded throughout
+     to any sensitivity-based authorization decisions, and may be forwarded throughout
      the XMPP network.  The content of these stanzas should not contain information
      requiring sensitivity-based dissemination controls.</p>
   <p>It is desirable to securely bind the security label to the object it labels.
@@ -779,6 +798,12 @@ And by opposing end them?
         </xs:annotation>
     </xs:attribute>
 
+    <xs:attribute name="from" type="xs:string">
+        <xs:annotation>
+            <xs:documentation>Target JabberId</xs:documentation>
+        </xs:annotation>
+    </xs:attribute>
+
     <xs:attribute name="name" type="xs:string">
         <xs:annotation>
             <xs:documentation>Name</xs:documentation>
@@ -839,6 +864,7 @@ And by opposing end them?
                 </xs:element>
             </xs:sequence>
             <xs:attribute ref="to" use="optional"/>
+            <xs:attribute ref="from" use="optional"/>
             <xs:attribute ref="name" use="optional"/>
             <xs:attribute ref="desc" use="optional"/>
             <xs:attribute ref="id" use="optional"/>