diff --git a/xep-0258.xml b/xep-0258.xml
index fe95c239..b44ed322 100644
--- a/xep-0258.xml
+++ b/xep-0258.xml
@@ -15,8 +15,8 @@
Add optional from attribute to catalog element for S2S requests. Make editorial changes. Illustrate XEP 45 security label room configuration. Make clarifications and minor editorial changes. Illustrate XEP Multi-User Chat room security label configuration. Make clarifications and minor editorial changes.
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 @@ ]]>
Note: The &IC-ISM; label example is for illustrative purposes only.
-The document details when security label metadata should or should not be provided, and how - this metadata is to be processed.
+The document details when security label meta-data should or should not be provided, and how + this meta-data is to be processed.
This document does not provide:
An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata +
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.
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.
@@ -255,11 +261,11 @@ sending a stanza without a label.Each catalog provided should only contain labels for which the client is allowed to use (based upon the user's authorization) in a particular - context (such as in chatroom). A catalog may not be include the + context (such as in chat room). A catalog may not be include the complete set of labels available for the use by the client in the context.
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.@@ -308,7 +314,11 @@ selector-value = (
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).
+ +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.
+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. +
+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.
Each server is expected to make a number of sensitivity-based authorization
decisions. Each decision is made by evaluating an Access Control Decision
@@ -415,7 +434,7 @@ selector-value = (
A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.
@@ -435,13 +454,13 @@ selector-value = (Clients SHOULD discover label feature and information on a per room basis.
Sending groupchat messages is similiar to sending normal messages, however +
Sending groupchat messages is similar to sending normal messages, however their are a few differences.
Groupchat messages are addressed to the room. The room clearance must be suitable for the message label, else it should be rejected.
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 - MUST only deliver messages to partipants for which they are cleared to + participants may be cleared for all labels allowed in the room. The server + MUST only deliver messages to participants for which they are cleared to receive.
Presence information is subject to sensitivity-base authorization decisions, however these decisions are made are made using a label associated with the - presence resource, such as a chatroom's label.
+ presence resource, such as a chat room's label.This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL; - elements are designed to hold a range of security labels formats. XML namespaces SHOULD + elements are designed to hold a range of security labels formats. XML name spaces SHOULD be used to avoid name clashes.
This document is all about authorization, a key aspect of security. Hence, security considerations are discussed through this document.
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.
It is desirable to securely bind the security label to the object it labels.
@@ -779,6 +798,12 @@ And by opposing end them?
+