On 21/01/2015 16:38, Kevin Smith wrote:
It is, but I don’t think privcomp mentions this requirement at all.*
It is not a requirement, because privileged entities can be used for
other things than an external PEP service. In addition it was written
before namespace delegation, I can add a
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
On 27/01/2015 16:30, Kevin Smith wrote:
It was not blocked by Council, it’ll be published once the Editors have a
chance.
Ok great :)
I'll publish a new revision for that and also namespace delegation I
still need to some change with last feedbacks, after I'll try a prosody
implementation,
On 27 Jan 2015, at 15:12, Goffi go...@goffi.org wrote:
On 21/01/2015 16:38, Kevin Smith wrote:
It is, but I don’t think privcomp mentions this requirement at all.*
It is not a requirement, because privileged entities can be used for other
things than an external PEP service. In addition
On 21 Jan 2015, at 15:00, Dave Cridland d...@cridland.net wrote:
On 21 January 2015 at 14:55, Kevin Smith kevin.sm...@isode.com wrote:
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
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
On 21 January 2015 at 14:55, Kevin Smith kevin.sm...@isode.com wrote:
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
