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

[Harald Tveit Alvestrand <harald@alvestrand.no>]

--On 7. november 2003 10:13 -0800 hardie@qualcomm.com wrote:

> > As John says in his note:
> > "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."
> >
> > I wouldn't say that it's worth much. But if the distinction is ever
> > worth making, I think this protocol should get one.
>
> Can you discuss a little further why?  Someone else's perspective on
> where this might fit as a service would help me mightily.

let's put it this way:

- getting internationalization, including translating strings between 
encodings, is not trivial. Been there, done that, got the scars.
- for every hard function that has to be done in code, experience shows 
that 90% of the time it's done, it's done by someone incompetent in the 
field. The classical answers to that are libraries and services.
- the library approach is well known in this area (gnu recode, IBM ICU, and 
so on and so forth). Issues with libraries are also well known 
(maintenance, memory footprint, added complexity, load-time issues)
- the service approach has not been explored. John has started exploring 
it, and gotten an "interested" response. It may turn out to "win" and 
become "well known". We don't know yet - in either direction. So I don't 
think that we should attempt to stop this experiment.

WRT system port:

- there's a mindset, and a *little* supporting code in OSes, that says that 
port numbers below 1024 are "more likely to be servers" - most OSes don't 
hand them out to applications looking for a port to send from. So there's a 
*tiny* advantage to having a server on a system port.
- with the current state of the universe, a well known service needs a 
fixed port number. Especially if it's UDP - while stateful firewalls 
recognize some request/response patterns in UDP queries, a lot of 
administrators haven't been upgraded yet.

I don't think there's much more to say. I found the arguments John put in 
his mail reasonably convincing - and the flopside I have in mind is this 
one:

If this level of argument isn't enough to allocate a system port, then 
where should the bar be?

And I think claiming (or seeming to claim) that we should hold this one 
request up because the IESG has to resolve the 10-year-old argument about 
whether system ports are useful or not is.... not useful.

                    Harald