[Standards] updated STUN discovery proposal

Mridul mridul at sun.com
Thu Apr 19 17:53:42 UTC 2007

This makes sense.
Looks like I missed this when I went through the archives, thanks.
One of the nagging concerns I am having of late is that specs might be 
getting retrofitted around a few base specs.
Under normal circumstances, I am a big proponent of a modular design of 
protocols : but there are cases where I get the feeling we might be 
stretching it a bit - sacrificing simplicity and compatibility just to 
'be right'.


Chris Mullins wrote:
> [This email is a re-post of one I sent on April 11]
> Matt Wrote:
> [Getting a list of STUN servers]
>> Is there any reason it needs to be so complicated?
> [...]
>> If there's not consensus, then maybe pubsub *is* a better choice 
>> (although still complicated).
> I keep thinking a Well-Known PubSub Node is actually quite a bit simpler
> than an IQ approach. My thinking is:
> 1 - The PubSub approach would require no server changes at all - it
> would immediately work with eJabberD, JabberD, SoapBox, WildFire, and
> XCP. With the custom IQ approach, each server needs to be updated to
> explicitly support the XEP, something that may (or may not) ever happen.
> I view this as a very large win, and would like to see this used as a
> general litmus test for protocol enhancements.
> 2 - The PubSub approach makes it easier to administer and makes changes
> to the list of STUN servers, and (importantly) that the administration
> would be identical across server implementations. With the custom IQ
> approach, each server is going to take a different approach for
> administration: JabberD & eJabberD are going to put it into their config
> files, and will require a restart any time the list is changed. SoapBox
> would add it to our Management Studio, you're going to add it to your
> Web Admin page, and who knows what the XCP guys would do.
> 3 - With PubSub you have some measure of control over who could see the
> list of STUN servers. This security comes for free with PubSub. With the
> IQ approach, any security is going to be custom for each server. I can
> see this being important. 
> 4 - With PubSub you get Update Notifications for free. With the IQ
> approach, it's going to be custom in each server, or not implemented at
> all.
> 5 - With PubSub you can authorize any number of people to publish new
> stun servers, how cool is that?
> I'm really not sure what complexity you're referring to with PubSub.
> It's a pretty simple protocol. 
> Certainly subscribing to a node is very easy. The actual code (from a
> real sample) looks like:
> NodeSubscribeRequest subscribe = 
> 	new NodeSubscribeRequest(pubsubJID, nodeID, JID.BareJID);
> NodeSubscribeResponse nodeResp = 
> 	(NodeSubscribeResponse)(s.Send(subscribe));
> Publishing something is equally easy (from the same sample):
> PublishItemRequest publish = 
> 	new PublishItemRequest(_pubSubService, _pubSubNodeId);
> publish.Items.Add(newItem);
> s.Send(publish);
> Getting the contents of that node is no more complex than it would be
> via IQ:
> // Ask the node for the list of items
> GetNodeItemsRequest itemReq = 
> 	new GetNodeItemsRequest(pubsubJID, nodeId, subscriptionID);
> GetNodeItemsResponse nodeItems =
> (GetNodeItemsResponse)(s.Send(itemReq));
> Processing the node contents is the same regardless of IQ or PubSub. 
> The only complexity I could see is initially creating the node. This is
> also pretty easy to do, so it's just a matter of timing. No different
> really than if it were the IQ approach. 
> --
> Chris Mullins 

More information about the Standards mailing list