On Jul 27, 2009, at 3:19 AM, Pedro Melo wrote:
Hi,
On 2009/07/23, at 23:29, XMPP Extensions Editor wrote:
Version 0.4 of XEP-0258 (Security Labels in XMPP) has been released.
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
should or should not be provided, and how the metadata is to be
processed.
Changelog: Update label catalogs to include user input selector.
(kdz)
Diff:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0258.xml?r1=2911&r2=3336
URL: http://xmpp.org/extensions/xep-0258.html
Section 3:
"The <label/> and <equivalentlabel/> elements each require a type=
attribute."
The examples lack the `type` attribute though.
This text needs some updating. The <label/> and <equivalentlabel/>
elements can contain a single element whose name/namespace indicates
the type of the label (as in the examples). I remove the text about
the type= attribute.
Section 4:
the definition of the <label> in the catalog shows something like
this: <label>"|"]*<label>
That's the ABNF description of a selector attribute value syntax.
(Looks kind of like XML, but isn't.) I'll clarify in the text.
It doesn't seem right nor consistent with the text that follows.
Maybe there was an escaping problem?
In example 8, the 'to' attribute is misplaced, should be in the top
level <iq> stanza. Also present in example 9, maybe it should be a
from there?
No. The client is requesting its server return the catalog for
example.com. Moving the to= to the <iq> stanza would imply the
client is requesting example.com return its catalog.
One thing that's not clear in the XEP is the expectation that clients
are to generally ask their server for catalogs (even of remote jids).
This is done for a couple of reasons. One, it allows their local
server to translate the remote catalog into the local policy. Second,
it allows the local server to filter the remote catalog based upon the
requestor's clearance (the remote server is unlikely to know what
clearance the remote (to them) has). I'll try to add some text here.
Section 5:
"Otherwise, the clearance input is the nil clearance. The nil
clearance is a clearance for which the ACDF always returns Deny when
given as the clearance input"
Isn't this mandating policy trough a XEP?
No. The policy can define default clearances/labels.
Shouldn't this be left to each particular installation? I could
decide to allow 'nil' clearance if the current message label is
unclassified or missing.
That would be done through defining defaults in the policy.
This text answers the question of what should an implementation do if
the policy does not specify defaults.
The same situation in the next paragraph: "The nil label is a label
for which the ACDF always returns Deny when given as the label input".
Best regards,
