On Wednesday 16 March 2011 02:33:07 you wrote: > On 16 March 2011 02:48, Justin Karneges > > If we're not querying for lists, then disco#items is out. But, we can > > still inherit disco category and type. > > > > How about this: > > > > <iq type="get" from="al...@example.com/home" to="b...@example.com" > > id="d1"> <query xmlns="urn:xmpp:tmp:delegation" category="pubsub" > > type="service" purpose="microblog"/> > > </iq> > > > > <iq type="result" from="b...@example.com" to="al...@example.com/home" > > id="d1"> <query xmlns="urn:xmpp:tmp:delegation"> > > <service jid="pubsub.example.com" node="urn:xmpp:microblog:0"/> > > </query> > > </iq> > > +1 for all the feedback Dave gave. > > If we would use the above example you gave, how would the "delete" case > work? Even in the the current examples in the XEP (deleting entries with > the type attribute), I would not want to delete all my chess or microblog > delegations with one shot.
Indeed. Basically, whether create, query, or delete, you'd need to specify all three of these parameters, and only 1 item would ever be created, returned, or deleted as a result. Now I am concerned about the disco identity fields being too specific. For example, couldn't a microblog be hosted on a "pep" service instead of a "service" service? Maybe we only want category and purpose for delegation, and drop type? It may not really matter though, as we could say that for microblogs you always delegate to "service" regardless of the actual disco#info of the JID being delegated to. Of course, a related question is whether the disco identities should match (i.e. any JID being delegated for a specific category+type combination also having that category+type in its disco#info). Justin
