On Oct 6, 2011, at 7:59 AM, Dave Cridland wrote: > On Thu Oct 6 12:45:50 2011, Kurt Zeilenga wrote: >> In initially writing the spec, my view was that a client should always be >> allowed to send a stanza with no label, mostly for backward compatibility >> with clients which don't support XEP 258. >> Most XEP258 clients I've seen generally allow generation of messages without >> labels. I suggest that XEP 258 that this is generally allowed unless >> someone can make a damn good argument that we should add a flag indicating >> to the client they should not generate messages with no label (unless the >> catalog contains an empty item). > > SHould there be a distinction between "This message has no XEP-0258 label, > possibly because I don't know how to put one on here", and "This message > explicitly lacks a label"?
> Ie, the distinction between no <securitylabel/> and one with an empty > <label/> element? I would have answered your question completely differently without this Ie. I would have read it: SHould there be a distinction between "This message has no XEP-0258 label, possibly because I don't know how to put one on here", and "This message explicitly lacks a XEP-258 label"? And to that, I would have said no. The use is expected to know what sensitivity each XEP-0258 label represents in the catalog they are offered, make some determination of which label to use in generating a message. In defense/gov't arenas, they are specifically trained on how to handle sensitive information. I'd expect the same in other environments to the extent the implied sensitivity of the labels are not self evident. Your ie., suggests you really asking "Is there a semantical difference between a stanza with no XEP 258 label and stanza with a XEP 258 label carrying an empty <label/> element?" Depending on the particulars of the security model and policy, there could be semantical difference and hence there could be handling difference evident to sender/recepient(s). And that difference, if any, would be something the training I mention would likely need to cover. Client developers, especially those implement policy-unaware clients, should not care if there is a <label/> element or what value it has when present. If the catalog contains a XEP258 label without a <label/>, they should offer the label as a choice as they would any other labels in the catalog. And if selected, produce the XEP 258 label as represented in the catalog. And on receipt of a XEP 258 label w/ a <label/> element at a client, nothing special happens. The client displays the marking as they would for any labeled message. -- Kurt
