Some quibbles first: 4.1 (roster access) would be nice to clarify that this is independent of the roster stuff in 6121, despite looking similar (none,to,from,both).
4.2. To which entities should this be sent? All entities including remote servers? Surely it shouldn’t be sending this without negotiation? 4.3 might be nice to clarify that this is standard 6121. 5.1 the MUST on default value here seems out of place. I’d suggest simply “This is the usual case” or such. 5.3 - the forwarded element needs to be wrapped explaining why the stanza is being forwarded. "The server sees that forwarded message type is ‘headline’” - it’s not clear to me what it being headline has to do with permissions here. There should be some normative language here explaining what these checks are. What happens if the priv. ent. tries to send a stanza it’s not allowed to? 6.1 should say how the directed presence is formed. (Presumably full JID from, component JID to, etc.). I think this is explicitly when the managed entity sends a broadcast presence. I think this is what 6.3 has in the examples, but examples aren’t normative. general: I dislike using namespace=‘presence’, when ‘presence’ isn’t an XML namespace. 6.4. All presence, including sub requests and errors? 7. SecCon, probably needs to include extra bits about ensuring the privent doesn’t send anything the manent wouldn’t be able to, and general could do with fleshing out. My last point, though, is that this doesn’t allow a component to implement presence-based pubsub stuff (not even the limited PEP profile), which it sets out to do, as it doesn’t have any way of delegating the incoming publishes, manual subscribes/unsubscribes, configuration etc. to the component. This seems significant! /K
