[Standards] Re: updated STUN discovery proposal

Peter Saint-Andre stpeter at jabber.org
Mon Apr 30 17:05:09 CDT 2007


V Unni wrote:
> Hi,
> Was going through stun-discovery proposal. Just wondering this concept 
> can be extended as a service discovery than just stun discovery.

We've had some discussions along those lines recently in the jdev room. 
It might be nice to query a server for services it knows about that meet 
some criterion (e.g., based on disco#info identity).

> Justification :
> =============
> 1) The current stun bis differs from the RFC 3489. Considering this, In 
> future more stun versions may exist  or co-exists with stun relay or 
> other p2p protocols.At a later point, if stun give way to some other 
> protocol, we need to obsolete our extensions.
>  
> 2) The IM is on its way to convergence, we require a  generic service 
> discovery mechanism  which can fit the future needs of evolving  services.
>  
> 3) The below proposed changes allows publist / discovery of multiple 
> services with single query ( ex: a jingle/voip session may need  
> services of stun and relay discovery).
>  
> 4) The below proposed changes on the stun discovery  are simple and 
> extend-able for the future needs.
> 
> Changes :
> ========
> name : from stun-discovery to service-discovery
> The new payload format:
> =======================
>         <service  xmlns='http://www.xmpp.org/extensions/xep-xxxx.html#ns'>
>           <server servicename=stun host='stun1.shakespeare.lit' 
> port='3478' proto=tcp/>
>           <server servicename=stun host='stun2.shakespeare.lit' 
> port='3478'proto=udp/>
>           <server servicename=stun-relay  host='turn.shakespeare.lit' 
> port='443'proto=tls/>
>         </service>

Presumably we'd need to have a registry of those servicenames, which may 
or may not map to the existing registry of service discovery identities:

http://www.xmpp.org/registrar/disco-categories.html

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070430/d327d619/smime.bin


More information about the Standards mailing list