address + port vs uri

[AMorgaut]

Looking to provide a Web API friendly version for our Raw Socket API, implemented by most platforms

I'll start with this first thought: "address + port vs uri"

In different places, we have to handle local and remote addresses and ports

The File API works with "blob:" URI scheme: http://www.w3.org/TR/FileAPI/#url

File API: Directories and System evoke a "filesystem:" uri scheme: http://www.w3.org/TR/file-system-api/#widl-Entry-toURL-DOMString
This which might be replaced by the recently proposed "app:" uri scheme in the context of packaged app: http://app-uri.sysapps.org/

And of course, the Web Socket API use the "ws:" and "wss:" uri schemes:

• http://www.w3.org/TR/websockets/#dom-websocket
• http://www.w3.org/TR/websockets/#refsWSP
• http://tools.ietf.org/html/rfc6455#section-11.1

It would then looks natural to me to use "tcp:" and "udp:" uri schemes
They could, as "http:", "ws:", "ftp:" and others, integrate the authority part in which can be specified the port number;
http://tools.ietf.org/html/rfc3986#section-3.2

I didn't saw yet "tcp:" uri scheme but "udp:" is listed as a "provisional uri scheme":

• http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Its basic syntax clearly show the "port" information:
udp://<server>[:<port>]/
A more advanced syntax provide additional informations, including multicast one:
udp://[<localaddress>@]<destination|multicastgroup>[:<port>]
The little issue is that it has been semantically declared for "MPEG Transport Stream over UDP" instead of only "UDP"

• http://www.iana.org/assignments/uri-schemes/prov/udp

One would say it might be easier to set address and port values to specific parameters or properties compared to constructing a text URI and potentially specify a new scheme.
But if some followed my point, they also think about the recent URL API : http://url.spec.whatwg.org/

• which may be expanded to support them
• or be the basis for a similar API supporting different schemes (URI instead of URL?)

An advantage, while potentially requiring such URI API, would be a simplification of the socket interfaces making them even more similar to the web socket one
It means for example that UDPMessageEvent could be a standard MessageEvent instead in which the remote address and port would be specified in the "origin" attribute:

• http://raw-sockets.sysapps.org/#interface-udpmessageevent
• http://www.w3.org/TR/webmessaging/#dom-messageevent-origin

It lets also room of course for "tcps:" and "udps:" uri schemes to handle ssl
(but we still need to think of the "exchange server" use case requiring deferred updateToSSL)

[AMorgaut]

Example of alternative interfaces with this approach:

[Constructor (optional UDPOptions options)]
interface UDPSocket : EventTarget {
    readonly    attribute DOMString       origin;
    readonly    attribute DOMString?     uri;
    readonly    attribute boolean         addressReuse;
    readonly    attribute boolean         loopback;
    readonly    attribute unsigned long   bufferedAmount;
    readonly    attribute ReadyState      readyState;;
                attribute EventHandler    ondrain;
                attribute EventHandler    onerror;
                attribute EventHandler    onmessage;
    void    close ();
    void    suspend ();
    void    resume ();
    void    joinMulticastGroup (DOMString multicastGroupUri);
    void    leaveMulticastGroup (DOMString multicastGroupUri);
    boolean send ((DOMString or Blob or ArrayBuffer or ArrayBufferView) data, optional DOMString? uri);
};

origin of type DOMString, readonly
The "udp:" URI including the IPv4/6 address of the interface, e.g. wifi or 3G, that the UDPSocket object is bound to and the local port. Can be set by the options argument in the constructor. If not set the user agent binds the socket to the IPv4/6 address of the default local interface, and to a random local port number (as if no port is specified in the URI)

uri of type DOMString, readonly
The "udp:" URI including the IPv4/6 address and the remote port that are used for subsequent send() calls. Null if not stated by the options argument of the constructor.

joinMulticastGroup
parameter
multicastGroupUri DOMString ✘ ✘ The multicast group address and port.

leaveMulticastGroup
parameter
multicastGroupUri DOMString ✘ ✘ The multicast group address and port.

send
Sends data on the given UDP socket to the address and port of the given uri.
If uri arguments is not given or null the destination is the default address and port given by the UDPSocket constructor's options argument's uri fields. If the port is not specified in the URI, the default port is used.
parameter
uri DOMString ✔ ✔ The address and port of the remote machine.

[ClaesNilsson]

Jonas comment on Jul 2nd:
I would recommend reaching out to IANA on this, and possibly the W3C webapps working group.
In general on the web platform, any URI can be used anywhere URIs can be used. So a blob: or a filesystem: URI works in as well <iframe src="..."> and XMLHttpRequest.open("GET", "...").
That wouldn't be the case with a tcp: scheme or a udp: scheme.
However, it's also not the case with ws: or wss:. In fact, tcp: and udp: work pretty similarly to ws: and wss:.
Generally I don't have a strong opinion, but minting new schemes tend to be a pretty political thing that you generally want to stay away from. But it might be the right thing to do.

[ClaesNilsson]

See

• http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0014.html
• http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0015.html
• http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0016.html

Before going to the URI community in the IETF and IANA I need to understand the motivations and benefits with the URI appoach. For WebSockets it is obvious that URL-addressing should be used as the WebSocket protocol is a higher level protocol and uses HTTP handshake but for the lower level udp and and tcp APIs a URI approach is not obvious.

As far as I understand a potential tcp uri would must always look something like "tcp://127.0.0.1:6789". So which is the benefit to use these kind of URIs instead of explict address/port arguments? For example would it facilitate sharing udp and tcp endpoints? Are there any bulit in JavaScript methods or commin libraries dealing with URIs that we can benefit from? Examples?

[annevk]

If you do this as URL, you have to call it URL, not URI, especially in the API. It seems WebRTC uses a URL for this too: http://dev.w3.org/2011/webrtc/editor/webrtc.html It's not entirely clear to me what a URL offers over distinct host and port though. I guess at the moment we don't expose primitives in http://url.spec.whatwg.org/ yet to parse host and ports, but we could certainly add those.

[AMorgaut]

Thanks Anne!

I proposed it to have this specification more consistent with what have been done in quite all other network related Web APIs. I think one of the reasons behind the choice of using URLs comes from the Web definition itself:

1. a system of globally unique identifiers for resources on the Web and elsewhere, the universal document identifier (UDI), later known as uniform resource locator (URL) and uniform resource identifier (URI);
2. the publishing language HyperText Markup Language (HTML);
3. the Hypertext Transfer Protocol (HTTP).[24]

http://en.wikipedia.org/wiki/World_Wide_Web

To call an API a Web API, it is probably best to use at least one of those 3 components

Regarding Benefits, I see:

• a simplified API in term of number of properties / parameters / options
• a simplified specification as reusing standard existing APIs (MessageEvent, Web Sockets)
• a single URL string is easier to store/retrieve, copy/paste, send, than a set of parameters/options
• TCPSocket constructor could have a compatible signature with the WebSocket one (maybe also the UDP one)

ex: As Data clones are not yet widely supported in Web storages, it is easier to store a url string than a couple of variables ip + port (would have to use either 2 keys, a JSON stringified object, or a string merging them with ":")

Technically, a single Socket constructor may support either web, tcp, and udp sockets, in which case udp specific method may work only if a udp scheme was used. If we don't provide it, I'm pretty sure a lib will do it.

[AMorgaut]

In this email Claes mentioned:

• http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0015.html

I proposed to also consider future usage of such URLs directly in HTML markup

ex:

a simple

<pre source="udp://..." ></pre>

could be used to show some log messages as they come (maybe via a dedicated <log> tag)

It would not be a direct advantage for the Raw Socket API, but using TCP/UDP URLs in this API could open such future opportunities.

[sicking]

On Sun, Aug 25, 2013 at 3:16 PM, Alexandre Morgaut
notifications@github.com wrote:

Thanks Anne!

I proposed it to have this specification more consistent with what have been not in quite all other network related Web APIs. I think one of the reasons behind the choice of using URLs comes from the Web definition itself:

1. a system of globally unique identifiers for resources on the Web and elsewhere, the universal document identifier (UDI), later known as uniform resource locator (URL) and uniform resource identifier (URI);
2. the publishing language HyperText Markup Language (HTML);
3. the Hypertext Transfer Protocol (HTTP).[24]

http://en.wikipedia.org/wiki/World_Wide_Web

To call an API a Web API, it is probably best to use at least one of those 3 components

Regarding Benefits, I see:

• a simplified API in term of number of properties / parameters / options
• a single URL string is easier to store/retrieve, copy/paste, than a set of parameters/options

I agree it's fewer properties, but I don't think it's simpler. It just
means that callers will have to do a bunch of string concatenation to
create the URL. If we really want to reduce the number of parameters,
just use something like "192.168.0.1:4711". Tagging a scheme at the
front of that just feels artificial.

Generally speaking when using URLs it brings other benefits. For
example it allows passing any urls, not just one of a specific
scheme. Or it allows passing file/path data along with the identifier.
What we're using here isn't a "resource" identifier/locator, but
rather a server identifier/locator.

We don't even support using tcp: and udp: interchangably. Much less
http: or ws:.

• a simplified specification as reusing standard existing APIs (MessageEvent, Web Sockets)

We're not able to reuse either of those APIs here anyway.

• TCPSocket constructor could have a compatible signature with the WebSocket one (maybe also the UDP one)

If this was possible then I agree that you'd have a stronger case for
using URLs/URIs. But currently that is not the case. I'd be interested
to see a proposal.

ex: As Data clones are not yet widely supported in Web storages, it is easier to store a url string than a couple of variables ip + port (would have to use either 2 keys or a JSON stringified object)

Technically, a single Socket constructor may support either web, tcp, and udp sockets, in which case udp specific method ay work only if a udp scheme was used. If we don't provide it, I'm pretty sure a lib will do it.

See above. Please make a comprehensive proposal for this if this is
what you think we should do. Given the different data models for web
vs. tcp vs. udp I'm not convinced that this would create a good API.

/ Jonas

[ClaesNilsson]

RESOLUTION at the Toronto F2F meeting on August 27-2013: close the udp/tcp scheme issue.

Comments raised at the meeting:

• It feels like a good thing, but you don't really need it
• i didn't see any strong arguments
• This should be proposed in the IETF
• The resolution of URL's is not addressed in the proposal (e.g. DNS entries, etc.
• This only covers a small part of URL space... no path, no fragment identifiers -- what does that mean

So the decision was to close the issue for now. It may later be reopened and then we must reach out to some other group, W3C TAG, IETF.

[marcoscaceres]

I've added a "later" label so this doesn't get lost (and it's easy to find, um, later.)

[AMorgaut]

Few comments hoping it can help

It feels like a good thing, but you don't really need it
i didn't see any strong arguments

Biggest argument to me would be Web API consistency

Note also that the WHATWG URL spec describe things that can be useful for this spec as:

• IPv6 & IPv4 Parsing
• hostname parsing (related to the new Allow to use domain name in remoteAddress #73 feature)
• giving such socket URL property to the URL() contructor would help the user to get out of the box its 'protocol', 'hostname' and 'port'

Other mentioned opportunity included the possibility to reuse such URLs directly from the HTML markup (in the context of privileged apps)

This should be proposed in the IETF
The resolution of URL's is not addressed in the proposal (e.g. DNS entries, etc.

As for a proposal I agree I did only the initial research I feel competent in like research of what exists in other related APIs and what schemes are already registered at IANA

This only covers a small part of URL space... no path, no fragment identifiers -- what does that mean

This is to me the least concern

It only means that used with a URL API those fields would be empty
Schemes currently listed in the URL spec includes "file:" that is not expected to handle query or fragments

WebRTC mentioned by Anne use 'turn:' and 'stun:' URLs that are also very different
see: http://tools.ietf.org/html/draft-nandakumar-rtcweb-stun-uri-08#section-3.1

[santoshbachkar19]

why use to websocket url parameter schema as " ws://localhost:8080.." ......if i write "http://8080.." it's allowed or not.