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

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

--On Tuesday, 04 November, 2003 08:20 -0800 Harald Tveit 
Alvestrand <harald@alvestrand.no> wrote:

> --On 3. November 2003 14:53 -0500 John C Klensin
> <klensin@jck.com> wrote:
>
> > 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.
>
> having a version number (first!) rarely wastes more than a few
> bytes, and if you turn out to need it, you really need it.
> I see the arguments for assigning the port "now" - but the
> version number issue clearly points out why assigning the port
> before thinking a bit might have been a mistake :-)

I am not resistant to the idea of adding a version number if 
that is what you/IESG want to do, but I did think about it 
before posting the internet draft and decided against it (i.e., 
the offer to put it in was _not_ an afterthought).  Just to 
gently push back on being simplistic about it at the "what harm 
can a few bytes do" level, the counterarguments are:

	(1) This is intended to be used, primarily, over UDP,
	with TCP as a fallback for long strings (or when UDP
	responses don't appear in a reasonable period of time).
	A few extra bytes may shift some uses into TCP, and that
	would be unfortunate if it isn't necessary.
	
	(2) I note that the "one string in, one string out"
	model used here has been successfully used in the
	Internet, and the ARPANet before it, for over 25 years.
	It is not exactly a new concept that requires extensive
	testing.
	
	(3) Similarly, the response code model is directly based
	on the one used in FTP, from which the one used in SMTP
	and other protocols is derived.  We've got more than 30
	years of experience with that one.
	
	(4) While I think I know enough to do it, specifying a
	version number in a way that makes it actually useful
	for subsequent generations of a protocol is not
	straightforward.  Indeed, for a protocol this simple, it
	is probably more complex than any other aspect of the
	specification.  The consequences of "put in a version
	number" without adequate consideration of its
	implications have been throughly illustrated by the
	debacle over the version number header in MIME.

regards,
       john