Thanks much for your comments. I've made changes to address the editorial issues you raised. For your other comments, I respond below.
On Oct 5, 2011, at 12:39 PM, Wayne Franklin wrote: > Section 5.2.3: Messages should probably be restricted to the room security > levels because the messages will be logged with the room messages. Yes, the room's restrictions ought to apply. This is the way we've implemented it. > Section 5.3: Collaboration Gateway currently adds security markings to > <presence/> and <iq/>. Any reason to make this prohibited in XEP-0258. Regarding <presence/>, it's my view is that either a user is authorized or is not authorized for a presence subscription. If you have the situation where a user is only authorized for a subset of stanzas associated with a presence subscription, you introduce a number of complexities and undesirable behavior at the subscribers. Regarding <iq/>, they are okay to have in type=set iq stanzas, such as the pubsub item publish case given in the XEP. But they are not appropriate in results or errors. This is because if there's a label, then there's going to be an entity which filters by it. And filtering results and errors is quite problematic. So, entities answering iq's are simply assumed to generate content acceptable for entities its to be passed to. > What about "portion markings"? For those who never known what a portion marking is, here's a quick definition: Portion markings/labels is used to indicate different sensitivities of portions of the content, whereas an overall marking/labels indicates the overall sensitivity of the content. There's no support for portion marking for a number of reasons. I don't see portion marking of a stanza as terrible useful given that most stanzas are self contained content elements. And I don't see portion marking for live, dynamic conversations involving multiple content elements. And portion marking introduces significant complexity in both enforcing entities (e.g., servers) and producers and consumers. > In Collaboration Gateway, we have secruity banners "UNCLASSIFIED/FOUO" and > portion markings "U/FOUO". From what I could tell from reading the CDCIE CPP spec, CDCIE CPP provides a long display marking and a short display marking, the latter produced in a manner consistent with markings used for portion marking, is contained in an attribute which indicates it a portion marking, but that it always labeling the same content as the security banner provided in the security banner attribute. > We use the full security banner for the room classification and the portion > marking for individual chat messages. Is there really portion marking going on? Is there any text in the CDCIE CPP which indicates the scope of either of the marking is greater than or less than the stanza? It seems to me that CDCIE is providing two markings it its label and asking clients display both. That, by itself, doesn't see like portion marking to me. I don't see a particular need for two display markings per label for prominent display with the labeled content. I can see the need for markings for other purposes, such as in operator selection of labels. That need was fulfilled by the introduction of selectors in the catalog. > ColorCSS should not be used because some of the colors (like fuscia and aqua) > are subjective. What aspects of the semantics of the color names is subjective? > What security labels are applied to error messages? None. For operational reasons, errors generally need to be passed along. Discarding them would be quite problematic. For this reason, error messages should not contain sensitivity content. (If the content is so sensitivity that the error can be delivered, the stream it came in ought to be closed with a stream error.) > What about history messages? "The server MUST only deliver messages to > participants for which they are cleared to receive." -- may apply Yes. History messages should be filtered (and are in M-Link). I'll add a note about that to the spec. > > Does the XEP say anything about Mr Unclassified entering a secret room and > tagging a message as SECRET (even though he doesn't know anything secret)? What should happen here depends on the security model used. In many models, attempts to generate a message for which would the generating entity is not cleared to read would be denied (stanza rejected). However, it's my understanding that some models allow for a user to generate for which they are not allowed to read. One might have a clearance which separately grants read and write access. The spec allows either model. Our implementation denies submission of stanzas the submitter is not allowed to read. (Our implementation is generally consistent with the SDN.801c model.) -- Kurt
