Re: [tsv-area] [tae] Transport negotiation

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Lloyd Wood wrote:
> Joe,
> 
> I'm interested in a parseable way to pass that information down from a
> URI and the program handling the URI.

OK...

> Right now, we can explicitly state 'http' or 'https'. These are presumed
> to live over TCP, and IP - whether to use v4 or v6 is usually determined
> directly by giving an address or by DNS. But, oddly enough, we can also
> explicitly specify the port number, which defaults to 80. So, even
> though http lives on port 80 (and https on 443), that can be overridden
> in the URI.

Right. The port number is determined by the service name (which doubles
as the application protocol name) by default, but since that number is
solely determined by the endpoints anyway, there's an override.
ou w
> Similarly, though http is expected to live over TCP, being able to
> explicitly override it in the URI if desired has merit in some cases.
> That is, 'http' would be the same as writing 'http-tcp'. 'http-sctp',
> for the work outlined in:
> http://tools.ietf.org/html/draft-natarajan-http-over-sctp
> means use a different transport - SCTP instead of TCP.
> 
> Doesn't it strike you as odd that we can, at a high uri level, specify
> the low-level port number, but not the details of the layering to be
> used for that port? By adding explicit detail in the URI, we are
> removing ambiguity.

The port number isn't low level; it's the highest level, at the same
level as the protocol name/service name (http, https). The address is
also application-layer (consider that http://www.a.com/ returns a
different result than http://www.b.com/ even if they resolve to the same
IP address, at least since HTTP 2.x AFAIR).

The fact that addresses have different formats (DNS name, IPv4 dotted,
IPv6 coloned) is the part you're trying to mimic, IMO, and the
implication that using an IPv4 dotted implies a particular network layer
(IPv4 packets). Right now, we can specify that only for numeric IP
addresses, not even for DNS names.

Note that we don't let that float, though - it isn't:

	http or https://www.a.com/

It's the floating part that doesn't make a lot of sense from a protocol
handshake viewpoint - regardless of the fact that it also doesn't map
well to existing protocol handshakes.

As to specifying the lower layers, that builds on the artifact of
numeric IP addresses implying network layer. I don't know if I think
this should be visible to the app layer (as the address necessarily is);
it seems to break a lot of the isolation that layering is intended to
provide.

- ----

If you're going to do this, though, I wonder if the syntax of that
shouldn't lie syntactically where it exists in layering:

i.e.:
	http://www.example.com/
would become, explicitly:
	http:80//tcp:nagle//www.example.com:v4/

I.e., tcp doesn't modify the http part; it modifies the service:port
*pair*, and isn't tied any more to that pair than it is to the DNS name.
The DNS name, further, requires a version as well. We could add explicit
options to TCP as shown above too.

The general form might thus be:

	protocol_ID[:defaut_override]*

And the general form of a URI would include:

	app proto_ID//[transport_proto_ID//]?net_proto_ID

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk9OeQACgkQE5f5cImnZrs6CwCg6cEhPjZ4BxkztAdEMHYucGys
OuAAniS1alup1A0U1MV9eQ/BTvqupRR5
=VBwp
-----END PGP SIGNATURE-----