Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery. Clarify syntax of selector= attribute.
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.
-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.
-The &LABEL; and &EQUIVALENTLABEL; elements each require a type= attribute. - The type= attribute indicates the type and encoding of the element's value. - The attribute type= value 'ESS' indicates the label is the - base64, as specified in &rfc4648;, encoding of the &BER; encoding of the &ASN.1; - eSSSecurityLabel type as specified in &rfc2634;. - Additional types may be registered (see 'XMPP Registrar Considerations').
+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.
+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.
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 @@
It is RECOMMENDED the server publish a catalogs of security label
+ 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. 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. It is RECOMMENDED the server publish catalogs of security label
for use by clients. 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. 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:
"|"]*
where <label> is a sequence of characters not including "|".
. +where <item> is a sequence of characters not including "|".
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 @@ ]]> -
The following example pair illustrates catalog discovery.
+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).