[whatwg] PeerConnection constructor: Init string format

[Harald Alvestrand]

BTW, I haven't been on this list that long... if anyone has advice on 
whether such discussions are better as buganizer threads or as whatwg 
mailing list threads, please give it!

            Harald

On 04/08/11 10:41, Harald Alvestrand wrote:
> Adding this to the public archive:
>
> The current (April 8) version of section 9.4 says that the config 
> string for a PeerConnection object is this:
> ---------------------------
> The allowed formats for this string are:
>
> "TYPE 203.0.113.2:3478"
> Indicates a specific IP address and port for the server.
>
> "TYPE relay.example.net:3478"
> Indicates a specific host and port for the server; the user agent will 
> look up the IP address in DNS.
>
> "TYPE example.net"
> Indicates a specific domain for the server; the user agent will look 
> up the IP address and port in DNS.
>
> The "TYPE" is one of:
>
> STUN
> Indicates a STUN server
> STUNS
> Indicates a STUN server that is to be contacted using a TLS session.
> TURN
> Indicates a TURN server
> TURNS
> Indicates a TURN server that is to be contacted using a TLS session.
> -------------------------------
> I believe this is insufficient, for a number of reasons:
> - For future extensibility, new forms of init data needs to be passed 
> without invalidating old implementations. This indicates that a 
> serialized JSON object with a few keys of defined meaning is a better 
> basic structure than a format string with no format identifier.
> - For use with STUN and TURN, we need to support the case where we 
> need a STUN server and a TURN server, and they're different.
> - The method of DNS lookup is not specified. In particular, it is not 
> specified whether SRV records are looked up or not.
> - We have no evaluation that shows that we'll never need the 
> unencrypted TCP version of STUN or TURN, or that we need to support 
> the encrypted STUN version. We should either support all formats that 
> the spec can generate, or we should get a reasonable survey of 
> implementors on what they think is needed.
>
> My alternate proposal:
> --------------------------------------------------------------
> The initialization string looks like this:
>
> {
>  “stun_service”: { “host”: “stun.example.com”,
>                    “service”: “stun”,
>                    “protocol”: “udp”
>                  },
>  “turn_service”: { “host”: “turn.example.com” }
> }
>
> The STUN server may either be an IP address:port literal, or be a 
> domain name. If it is a domain name, the procedure in section 9 of RFC 
> 5389 (SRV record lookup, with fallback to port 3478 (STUN) or 5349 
> (STUN over TLS)) is used to establish the IP address and port to use 
> for STUN and TURN.
> If “service” and “protocol” are omitted, they are assumed to be “stun” 
> and “udp” for stun_service, and “turn” and “udp” for turn_service.
> For TURN, the procedure is defined in RFC 5766 section 6.1. The 
> procedure of RFC 5928 (using S-NAPTR applications) is not used.
> ------------------------------------------------------------------------------------ 
>
>
>
>
>