RE: Application for port-number (system-klensin) (revised) (fwd)

[hardie@qualcomm.com]

I see no reason why this needs to be a system port, and I will bet a dozen donuts
that we'll have every problem we currently have with whois and finger with this
very quickly.  I can virtually guarantee you, for example, that some bright spark
will start sending bitstrings separated by spaces so they can do multiple translations
at once (if I have this need for two different labels in an fqdn, after all, why send
two messages?).  Some other bright spark may, of course, go a different way,
and we'll be back to the fun and games in we have now in whois parsers.

I'm also really not convinced of the need for these servers in the idna framework.
If the punycode conversions can be done relatively easily on a mid-level phone
(and I've just confirmed that the tables and memory fit in phones
common in India and Brazil, two of our touchstones for these things), why is
this being done over the flipping network?  What devices need this and can't
do it for themselves?

Maybe I just need more caffeine, but I don't see this as useful infrastructure or
a good protocol model.  I'll try to talk to John about this in Minneapolis, but
can we hold off in the mean time?
				Ted

At 8:44 AM -0800 11/05/2003, Harald Tveit Alvestrand wrote:
>Based on this protocol definition, I think we should tell IANA to give him the system port number.
>Thomas - your opinion? Others?
>
>               Harald
>
>---------- Forwarded Message ----------
>Date: 5. november 2003 10:24 -0500
>From: John C Klensin <klensin@jck.com>
>To: iana@iana.org
>Cc: harald@alvestrand.no
>Subject: RE: Application for port-number (system-klensin) (revised)
>
>Michelle,
>
>Revised version, per discussion with Harald.
>
>Harald,
>
>New I-D follows under separate cover (no need to clutter Michelle's
>mailbox).
>
>   john
>
>
>-----
>
>
>
>Application for System (Well-Known) Port Number
>
>Name :
>John C Klensin
>
>E-mail :
>klensin@jck.com
>
>Protocol Number :
>TCP & UDP
>
>Message Formats :
>The message from client to server is
>  V S T Length String
>V=decimal version number, always "1" for this version; an ASCII space;
>S=decimal source code, spelled out in ASCII digits (see below); an
>ASCII space; T=decimal target code, also spelled out in ASCII digits,
>an ASCII space; Length of string in bits, also a decimal-base number
>spelled out in ASCII digits; an ASCII space; and an unrestricted
>bitstring.  Any bits beyond the length are ignored, a shorter string
>than the length is an error.  The reply string consists of a three
>(decimal) digit reply code, an ASCII space, a length (as above),
>another ASCII space, and a string.
>
>Message Types :
>There is one input message which is essentially a translation request, and
>one output message which is a reply to that request.
>
>Message opcodes :
>There are no operation codes; this protocol is designed to be terribly
>simple.  See (3) and (5).
>
>Message Sequences :
>This is a relative of the proven Whois/Finger/ etc model: open connection
>(if TCP), one message from client to server, one from server to client,
>close connection (if TCP).
>
>Protocol functions :
>This protocol is used to translate (or recode) one string (coded in one
>character type/form) into another one.  Its primary use is to support
>internationalization by providing a quick way to get Unicode (in any of the
>usual formats) into IDNA/Punycode and back, although other conversions are
>possible and defined. There will eventually be an IANA registry for coding
>types; at present, they are listed in the I-D.
>
>Broadcast or Multicast used ?
>no
>
>How and what for Broadcast or Multicast is used (if used):
>
>
>Description :
>draft-klensin-name-munging-01.txt.   Version 00 of that draft is now
>on the IETF Web site and shadows.  Version 01, which contains the
>addition of the version number and some additional clarifications,
>will be posted immediately after IETF 58.
>
>Name of the port :
>Name Munging
>
>Short name of the port :
>namemunge
>
>
>
>
>
>---------- End Forwarded Message ----------