> It's the concept of well-known ports that's broken, not the provision for 65K > ports. offhand I don't see why we need two kinds of names for services, because that creates the need for a way to map from one constant to another - and that mapping causes failures which seem entirely unnecessary. I do see the need to allow applications to talk to non-default service names (say for testing or other special cases) but that's a separate issue. regarding service names, a bit string should be fine, as long as it's not restricted to some short length. 16 bits is not enough in the long term. I don't have much of a problem with services named using character strings either, except that these days such discussions inevitably bring up internationalization issues that I'd rather avoid. most of this is probably moot as I doubt we have the luxury of starting from scratch. but in terms of where we want to be, I think it makes more sense to extend the port # space than to insist that everyone use a separate and less reliable means of mapping between character service names and port #s. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf