On Thu, Oct 6, 2011 at 7:30 AM, Kurt Zeilenga <[email protected]>wrote:
> 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. > I only put this here because there was a question in the XEP. If a decision has been made, the question should be removed. > > > 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? I missed the reference to CSS3 + "orange"... my bad. > > 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 -- Wayne Franklin Trident Systems, Inc. One Copley Pkwy Ste 420 Morrisville, NC 27560 919-388-1263
