G'day Kev,
sorry for the late answer.
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).
It is related to RFC 6121, there is only "none" and "both" in addition
for managing the permission
4.2. To which entities should this be sent? All entities including remote
servers? Surely it shouldn’t be sending this without negotiation?
It is sent to the managing entity only, so it can know which permission
has been allowed by server administrator. There was negociation in
previous versions, but it was requested to remove it to simplify the
implementation. Indeed, it makes sense to give the permissions in the
configuration and only advertise the managing entity of what it can do.
As the "client mode" has been removed following the discussion after the
last veto, the negociation doesn't seem necessary anymore.
4.3 might be nice to clarify that this is standard 6121.
it is written "(as described in RFC 6121 [2] section 2),", is this not
enough ?
5.1 the MUST on default value here seems out of place. I’d suggest simply “This
is the usual case” or such.
The MUST is here to assure that in case of omission, there is no
dangerous permission given. It is inherited from the previous revisions
where there were a negociation, but it is still appropriate here in my
opinion.
5.3 - the forwarded element needs to be wrapped explaining why the stanza is
being forwarded.
indeed, according to XEP-0297 business rules, I should (and will) add this:
" 5. When a forwarded stanza forms part of an encapsulating protocol,
the <forwarded/> element SHOULD be a child of a tag of that protocol,
and SHOULD NOT be included as a direct child of the transmitted stanza."
"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.
After a discussion in a MUC room with Sergey Dobrov, we have thought it
would be safer to limit the type to "headline" because with other types
you can fake message from managed entity. But again that's inherited
from "client mode" of previous revisions, I guess we can remove it now
(because the component is validated by the server administrator).
There should be some normative language here explaining what these checks are.
There are only 2 checks to do (message type - which may disappead has
just said -, and message from which MUST be the bare jid of the managed
entity). Using a normative language for that looks like a bit
overcomplicated.
What happens if the priv. ent. tries to send a stanza it’s not allowed to?
As explained at the end of 5.1, the server returns a not-authorized
stream error.
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.
The norme is RFC 6121 section 4.6 (quoted at the end of 6.1), the
example is here just to be more explicit. The beginning of 6.1 explain
that it is the presence of the managed entity which is sent to the
privileged entity.
Maybe it's not clear enough that managed entity is necessarily a full
jid (it's a connected resource) ?
general: I dislike using namespace=‘presence’, when ‘presence’ isn’t an XML
namespace.
I understand that, but there is no specific namespace for <PRESENCE/>
and <MESSAGE/>, and that was a way to stay coherent with the <IQ/>
permissions. As today the protoXEP has been restricted to only "roster"
"message" and "presence", I can rename the attribute to something else.
6.4. All presence, including sub requests and errors?
indeed it is not necessary to have sub request and errors, I'll restrict
that on next revision.
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.
I can add some bits yes.
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!
It can only be used for PEP when namespace delegation (XEP-0355) is also
active, that's why I have proposed the 2 protoXEPs. But privileged
entity can also be used for other things e.g. a component which manage
the roster (a gateway for instance).
/K
Thanks for your feedbacks.
