[JDEV] Ambiguity in jabber:iq:browse "pushes"

[Jens Alfke]

I'm trying to grok the vague description of jabber:iq:browse on the 
"Protocol-Draft" section of the DocZone:
	http://docs.jabber.org/draft-proto/html/browsing.html
As always, if this is the wrong thing to look at and there's a 
conflicting but more accurate description somewhere else, let me know!

The primary thing that's gotten me confused is the apparent ambiguity of 
a "set" query using this namespace. It seems to be used for two entirely 
different things:
(1) Sent to a watcher as a "push" to notify a watcher of new data in the 
*sender*s browse space.
(2) Sent to a browse source to edit (add/modify/delete) data in the 
*receiver*s browse space.

In general I don't see how these two things can be distinguished from 
each other. If you look at the two examples in the "Live Browsing" and 
"Editing" sections, they are fundamentally identical; only the type of 
data elements in the payload is different. Yet the two have very 
different meanings and in fact describe data on two different JIDs! The 
sinking feeling I have is that when receiving such a "set" you have to 
make a judgment call based on the exact type of data contained and the 
exact JID you received the query from. I imagine that this is _usually_ 
possible, but it makes me nervous and doesn't seem like a good design.

IMHO it's the "push" feature that seems wrong -- it's a misuse of "set". 
The exact meaning of "get" and "set" is already pretty vague due to all 
the uses they've been put to, but it seems that you can at least rely on 
the fact that they apply to the _receiver_ of the query. But browse 
pushes turn this on its head.

What this really points out is the lack of a general purpose 
subscription/notification mechanism in Jabber, which is ironic since 
this is so central to presence. Jabber's <presence> element and its 
subscription model are completely hardwired for one particular type of 
data (presence state and status text) and cannot be used for anything 
else. There is a lot of other info that one might want to subscribe to, 
ranging from buddy icons to lists of shared files to news headlines, but 
no good mechanism to manage the subscriptions and notifications required 
by real-time updates of this information.

Any comments? Am I totally off-base here? Are the existing efforts to 
remedy this? (I'm aware of the Profiles JIG and have just joined it.)

--Jens