[Standards] updated STUN discovery proposal

[Bruce Campbell]

On Thu, 19 Apr 2007, Peter Saint-Andre wrote:

> Matt Tucker wrote:
>>>> If the list of STUN servers is provided via disco#items then you'd have 
>>>> to poll for updates, which seems undesirable.
>>> Is it expected that there will be frequent updates to this list of STUN 
>>> servers ?
>> Yeah, I just don't get this. STUN servers just aren't going to change in
>> 99.99% of deployments. Who has the requirement that STUN servers change?
>> I keep asking and getting no reply. :) If the requirement is an imagined
>> one, we should go back to simple IQ and get rid of the push stuff.

Why is the expectation there that clients are going to bother subscribing 
to that node?  They're just going to ask for it whether its within pubsub 
or simple iq.

About the only things pubsub gives you is a well-known-location, and being 
able to shove access control decisions off to someone else.

> For that matter, why not encourage people to use the SRV lookups that have 
> been defined for discovery of STUN servers and not try to do everything over 
> XMPP?

Current draft reads:

 	Therefore, this document defines a way for an XMPP server to
 	advertise a list of STUN servers. This method SHOULD be used only
 	as a fallback when DNS SRV lookups are not possible for the client
 	or server.

Its not quite the "by gum, we're going to use this one hammer for 
everything" issue that you thought.

-- 
   Bruce Campbell.

   Though wouldn't mind seeing a TTL value in the STUN list supplied via
   XMPP, just to have some marginal control on how often clients ask for
   an updated list.