Philipp, It's not terribly clear to me which of your comments below is the issue you feel is blocking publication. I agree the spec is rough around the edges, and it's not how I'd do things, but it doesn't look like a non-starter to me.
On 29 September 2014 12:43, Philipp <[email protected]> wrote: > Am 25.09.2014 um 11:02 schrieb Kevin Smith: > >> Logs: http://logs.xmpp.org/council/2014-09-24/ >> >> 1) Roll call >> Kev, Tobias, Lance, Philipp present, Matt sends apologies >> >> 2) http://xmpp.org/extensions/inbox/privilege-component.html >> Accept as Experimental >> >> No objections from Kev, others to vote onlist >> > > I think this needs more work. I'll leave the oauth part to lance. > > Example 1: > <iq from='pubsub.capulet.net' type='get' id='privilege1'> > <query xmlns='urn:xmpp:privilege:0' type='request' privilege='admin'> > <perm namespace='jabber:iq:roster' type='both'/> > <perm namespace='http://jabber.org/protocol/pubsub' type='both'/> > </query> > </iq> > > I'd suggest renaming the element to <privilege/> -- we don't use <query/> > that much anymore. > > I don't see why this element needs an extra type attribute. Request maps > to iq-get, allowed to iq-result and errors are already transported via > iq-error. > > Example 2: > I do not want to open the can of worms of a server accepting only a > partial set of privileges. So I would recommend returning an empty result. > Otherwise the client has to check the server returned what the client asked > etc. > > The values of the permission type (read/write/read-write) should be > explained earlier. I only understood it when reading the description in the > example form. > > > "admin mode" seems oddly named. "component mode" maybe? > > In admin mode, the privileged entity MAY be able to emit IQ stanzas > in the same way as any entity, including managing roster or > accessing persistent storage. > > If that implies that a component sends with other from than it authorized > for, this is not allowed by XEP-0114: > The domain identifier portion of the JID contained in the 'from' > attribute MUST match the hostname of the component > > > typos: > Server Accept -> Server Accepts (same in 4.1.3) > 4.2.: > juliet -> Juliet > publiser's -> publishers(?) > > > > > 3) http://xmpp.org/extensions/inbox/cmr.html >> Accept as Experimental >> >> No objection from Kev or Lance, others to vote onlist >> >> 4) Fippo's report on UPnP >> >> http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf has >> been published after review by the UPnP liason team >> >> 5) Date of next meeting >> >> 2014-10-01 15:00Z >> >> 6) Any other business >> >> None >> >> Fini >> >> >
