[whatwg] PeerConnection constructor: Init string format

[Harald Alvestrand]

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.
------------------------------------------------------------------------------------