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
This commit is contained in:
Kurt Zeilenga 2009-07-27 18:00:51 +00:00
parent 3bb49212ac
commit d1178200c5
1 changed files with 35 additions and 16 deletions

View File

@ -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'>