draft-klensin-name-munging and well-known port request

[John C Klensin <klensin@jck.com>]

Hi.

Folks, I thought a bit more explanation on this might be helpful.

I wrote that proposal on the assumption that it would be useful 
for some marginal internationalization applications, people 
building apps as scripts, and transitions of existing apps to 
IDNA by patching.  On that basis, I figured I'd get some 
comments in Minneapolis, ask for a user port, make another pass 
on the document, and try to publish the thing as an experimental 
RFC.  It turns out that it got immediate traction.  I've got one 
full implementation in hand in addition to my hacking around, 
and offers of two others.  I've also got offers of high-capacity 
servers to run the thing on a "public good" basis.

I suspect that should help remind all of us about the advantages 
of really simple protocols.

The thing also apparently has some real potential as a plugin 
killer as the best path to internationalization of domain names 
-- something that all of us should consider desirable if we take 
IDN seriously.

If it is to be significantly used, "one port now, another later" 
is seriously undesirable.  And the advantages of a well-known/ 
system port for an application protocol that provides a support 
function should be obvious if the distinction is worth anything 
at all.

With regard to the "what if it changes" question, my hope and 
expectation is to keep it very simple.  It is simple enough 
today that the issues that might arise with some protocol that 
takes 20 (or 50) pages of text to describe should not apply 
here.  However, if the IESG remains concerned about the issue, I 
suggest that we modify the thing, right now, to include a 
version number parameter (probably as the first one) that would 
avoid needing to assign a second port if there are changes.

Extended debate about this will hold up a bit of 
internationalization work, and momentum, which exists right now. 
I hope that can be avoided.

thanks and regards,
     john