Mark Andrews wrote:
I know SRV and other similar proposals so far are not
very compatible with URL syntax and should better be
simplified.
The only thing difficult to map was non-default ports and that could
easily have been addressed.
That's why simplification is desired. See below.
Remember SRV required a seperate RFC to
specify how to map existing services on to it. HTTPS just prefixed the
label "_<port>”. That could have easily been done with SRV.
HTTPS and SVBC are just SRV on steroids.
Nothing should be HTTPS specific. What is essentially necessary
is to map:
<scheme>:[<userinfo>"@"]<host>
and
<scheme>:[<userinfo>"@"]<host>":"<port>
to
<scheme>:[<userinfo>"@"]<realhost>":"<realdefaultport>
and
<scheme>:[<userinfo>"@"]<realhost>":"<port>
for which RRs like:
_<scheme>.<host> MAP <realhost> <realdafaultport>
should be just enough.
But if you insist, UPnP by Microsoft has been implemented
on almost all NAT boxes. There even exists PCP.
But how much has been implemented in CGNs and how many ISP’s
enable it if it is implemented?
As most users are satisfied without port forwarding and even
those who aren't merely need static configuration on CGNs,
why do you bother?
> Getting IPv4 continue to work
> just add layer upon layer of hacks which we are all continuing
> to pay for.
We don't need any new mechanism to keep using IPv4 if users can
accept external servers, which is the usual case for SMTP and DNS.
On the other hand, people still insisting on IPv6 are,
as you can see here, still arguing for hacks, most of which
are well known and already abandoned but, worse, some of
which are new.
Masataka Ohta
