On Feb 11, 2010, at 10:06 AM, John Keeping wrote: > In XEP-0258 (Security Labels in XMPP) it is unclear what the constraints > are for the location of <securitylabel/> elements. For reliable > application of labels to content there needs to be a clearer indication > of precisely where in the XML a label can appear and what it should > apply to. > > It seems from paragraph 9 of section 5 that the intent is to label only > complete stanzas (as opposed to permitting content labels that apply > only to parts of the stanza).
This is the intent. That is, it is intended that that the <securitylabel/> element apply to the stanza as a whole, and that generally a stanza would contain zero or no <securitylabel/> elements and, when present, placed appropriately. I note that there may well be, depending on the design of stanza signing solution used, the possibility that a stanza would contain more than one <securitylabel/> elements. This case will need to spelled out in detail once we have an appropriate signing solution such that it clear which label is effective. (I'm currently drafting a XMPP stanza signing solution based upon encapsulating XML DSIGs.) > This could be made clearer by expanding > sections 5.1 and 5.2 to specify that <securitylabel/> elements can occur > only as direct children of the <message/> element. > > For <iq/> stanzas the same approach cannot be taken since only one child > of the <iq/> element is permitted. Is the expectation here that any > <securitylabel/> element (no matter how deeply nested) should apply to > the entire stanza? If so, how should multiple <securitylabel/> elements > (possibly at different depths) be handled? It is expected that the <securitylabel/> be a direct child of the <iq/> element's direct child, and that it applies to the stanza as a whole. Note that the data carried by the <iq/> might contain <securitylabel/> elements, such as in label catalog transfer. Such labels do not apply to the stanza. I will try to address your comments in the next revision of XEP 258, which I am now working on. > > > [ One other minor comment, in the second sentence of paragraph 6 of > section 5 "A policy-aware may..." should be "A policy-aware client may..." ] Good catch. > > > John > > -- > John Keeping > Metanate Ltd, UK > www.metanate.com (Software consultancy) > www.schemus.com (Data synchronisation) > > This e-mail and all attachments it may contain is confidential and > intended solely for the use of the individual to whom it is addressed. > Any views or opinions presented are those of the author and do not > necessarily represent those of Metanate Ltd. If you are not the > intended recipient, be advised that you have received this e-mail in > error and that any use, dissemination, printing, forwarding or copying > of this e-mail is strictly prohibited. Please contact the sender if > you have received this e-mail in error.
