Begin forwarded message:
> From: XMPP Extensions Editor <[email protected]> > Subject: [Standards] LAST CALL: XEP-0258 (Security Labels in XMPP) > Date: October 4, 2011 5:37:12 PM EDT > To: [email protected] > Reply-To: XMPP Standards <[email protected]> > > This message constitutes notice of a Last Call for comments on XEP-0258 > (Security Labels in XMPP). > > Abstract: This document describes the use of security labels in XMPP. The > document > specifies how security label meta-data is carried in XMPP, when this > meta-data > should or should not be provided, and how the meta-data is to be processed. > > URL: http://xmpp.org/extensions/xep-0258.html > > This Last Call begins today and shall end at the close of business on > 2011-10-21. > > Please consider the following questions during this Last Call and send your > feedback to the [email protected] discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Yes > 2. Does the specification solve the problem stated in the introduction and > requirements? Mostly > 3. Do you plan to implement this specification in your code? If not, why not? Probably > 4. Do you have any security concerns related to this specification? No > 5. Is the specification accurate and clearly written? Yes > > Your feedback is appreciated! Comments and questions: Section 1 Introduction: "For instance, message" should be "For instance, a message" Section 1 first bullet: "client might discover" should be "client to discover" Section 1 last two sentances seem to contradict each other Section 1 "enforce" should probably be "enforced" or "in force" Section 4 "A catalog may not be include the complete set of labels" should be "A catalog may not be included in the complete set of labels" Section 5 Use in XMPP: "A policy-aware may" should be "A policy-aware client may" Section 5 promiently should be prominently Section 5 approrpriate should be appropriate Section 5.2.3: Messages should probably be restricted to the room security levels because the messages will be logged with the room messages. Section 5.3: Collaboration Gateway currently adds security markings to <presence/> and <iq/>. Any reason to make this prohibited in XEP-0258. Section 6: The second "is" should go What about "portion markings"? In Collaboration Gateway, we have secruity banners "UNCLASSIFIED/FOUO" and portion markings "U/FOUO". We use the full security banner for the room classification and the portion marking for individual chat messages. ColorCSS should not be used because some of the colors (like fuscia and aqua) are subjective. What security labels are applied to error messages? "The stanza SHOULD be discarded with, if approrpriate, an error response. Such error responses SHOULD NOT include content from the violating stanza, excepting that necessary to well-formed error responses." What about history messages? "The server MUST only deliver messages to participants for which they are cleared to receive." -- may apply 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)?
