RE: FW: Application for port-number (system-klensin)

["IANA" <iana@iana.org>]

The rules were, as confirmed back when I came on board by Fred Baker
and John Klensin, that for a system port number you needed either
IESG approval or IETF Consensus.  Because of the limited number of
system port numbers, it was not first come first serve.  RFC 2780
does not clearly state what the rules were for user vs. system port
numbers.  We hae some ideas of getting a new document out but it
has not been on our priority list at the momment.

John mentioned he would send a note to the IESG explaining further.
I'm sure he would be happy to answer any questions.

Please let me know when a decision from the IESG has been made.

Thanks,

Michelle


-----Original Message-----
From: hardie@qualcomm.com [mailto:hardie@qualcomm.com]
Sent: Thursday, October 30, 2003 12:05 PM
To: IANA; IESG
Subject: Re: FW: Application for port-number (system-klensin)


I don't know what the rules are, but if we can delay it, I think we
should.  Building a new protocol based on this view of message
sequences at this point just doesn't seem like a good idea.
I'd like to see the draft and talk to John before we approve it.

			regards,
				Ted


At 11:12 AM -0800 10/30/2003, IANA wrote:
>IESG,
>
>We have received the following System port number
>application.
>
>Can this be approved by the IESG before the document
>gets approved for publication as an RFC?
>
>Please let me know.
>
>Thank you,
>
>Michelle
>IANA
>
>
>
>-----Original Message-----
>From: klensin@jck.com [mailto:klensin@jck.com]
>Sent: Thursday, October 30, 2003 9:54 AM
>To: iana@iana.org; klensin@jck.com
>Subject: Application for port-number
>
>
>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
>   S T Length String
>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-00.txt.   Version 01 of that draft will be
>posted immediately after IETF 58, but differs only in having some textual
>clarifications.
>
>Name of the port :
>Name Munging
>
>Short name of the port :
>namemunge