CircleID

As a followup, after I submitted the above article I read about:

http://www.cp80.org/content/solutions/community-ports

which is a very similar idea (derived independently; I guess great minds think alike, or fools seldom differ).

This is a terrible idea for mostly technical reasons.

There's only about a thousand port numbers that can be used by net services. (Port numbers are a 16 bit field, but numbers above 1024 are traditionally available for dynamic allocation as programs need them, and it would require a global software upgrade to change that.)

Historically the demand for port numbers has been quite low, since the only reason to allocate one is when someone comes up with a new technical communications protocol.  The allocation process has been quite nerdy. Part of the IETF's RFC publication process is to note which RFCs define something that needs its own port.  In practice, a new port number gets assigned a few times a year.

But if you were to assign semantics to port numbers, there'd be a huge land rush, they'd become valuable, and you would run into exactly the same arguments about allocation that you have now about TLDs, only it'll be worse since unlike TLDs, we can and would run out of available port numbers.

I believe it is port numbers above 49151, not 1024, that you refer to, see here, and note that there is a section "The Dynamic and/or Private Ports are those from 49152 through 65535." Those between 0 and 1023 are the ones that are restricted to "system (or root) processes or by programs executed by privileged users."

The ones between 1024 are 49151 are still somewhat limited in number, of course, albeit 48 times less limited than below 1024, and ICANN/IANA would have to be conservative in allocating any additional "evil ports."

No, it's ports above 1024. I'm referring to what TCP software on actual computers actually does. Every TCP connection requires a port number at both ends, and the normal approach in TCP software is to for the client end of a connection to pick an arbitrary port number which often is down in the 2000 or 3000 range.

But whether the limit is 1K or 64K, the number is small enough that hoarding would happen. I can assure you that IANA would be no match for the speculators, and we'd have a port shortage, a flurry of lawsuits, or probably both.

As soon as you need an allocation policy, you have all the same problems you have with the TLD allocation policy, so what have you accomplished other than to make it much harder for actual new protocols to get the port numbers they need?

I can think of a large number of variations on this theme, such as the inclusion of a keyword in the URL, using "xxx" as a bottom-level domain name (instead of the traditional "www"—cute, huh?), using PICS or various other content-marking schemes, and so on. But then it struck me that I'm not sure what the problem is. Consequently, I don't know if any of my solutions (or the port number solution) actually solve anything.

What problem are we trying to solve, here? I don't think there's any agreement as to what the problem is, or even if there is a problem.

Are we looking for a technical solution to the problem of keeping kids away from porn on the Internet? (Gloss over the globally inconsistent definitions of "kids" and "porn" for now.) Is that what ".xxx" is about? Are we saying we don't need ".xxx" because we have other ways to label porn? Well yeah, PICS is over ten years old. Remember PICS? I'm sure some of you remember it. PICS shows that technical solutions to the kids+porn problem are easy: it's just getting all the necessary parties to actually use them that's hard.

But it seems to me that the ".xxx" registry idea was not proposed as a protective measure. Like most applicants with a TLD proposal, this was primarily intended to be a money-maker, and I'm pretty sure they don't care whether the money is from real pornographers or preemptive registrations. Money is money. Is the problem that ".xxx" would mean another domain name land-rush? That didn't stop ".eu" did it? Why do we care about a ".xxx" land-rush?

If your concern is not the land rush itself, but rather that a name associated with you may be registered under ".xxx", and this possibility doesn't sit well with you, then go ahead and oppose ".xxx" on the basis of "potential for malicious use" or something. There's no real need to offer alternatives if this is the problem: just say "no".

Solutions are a dime a dozen. Being able to actually identify the problem: that's gold.