Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Lars Eggert wrote:
> Hi,
> 
> On 2010-1-11, at 14:27, [e-mail] wrote:
>> (1)
>> Paraphrased from collected wisdom:
>>
>>   "allocate" or "assign" :
>>         IANA choses the code point, hands it out and
>>         publishes it; if the requester proposes a value,
>>         it is not binding for IANA and can be changed
>>         without further notice/interaction.
>>
>>   "register" :
>>         The requester usually proposes an (already established) code
>>         point, and if feasible, IANA accepts and publishes the value;
>>         otherwise, IANA must contact the requester for another
>>         proposal and iterate the procedure until acceptable.
> 
> I'd like to hear if IANA is of the same opinion. My impression was that assign = register.

There's a third variant, and it isn't covered above:

	requester usually proposes a code point, and IANA
	can either approve it or propose a different one.
	IANA usually confirms the requester's acceptance
	of the code point offered.

>> (3)
>> Furthermore, to make sensible use of Service Names w/o assigned
>> port number, the Transport Protocol(s) field should not be made
>> optional (as in the predraft I got), but mandatory; otherwise
>> the clarified rules for SRV owner naming would lack a fundament.
> 
> Why? A service name is a name for a service, and not for a service/transport combination.

IMO, this basically treats SRV names as old port numbers were treated -
i.e., ask for a name, get ALL transports. That's how port number
assignments were done until recently, where now only the needed
transport is assigned.

So IMO a service means something only relative to a transport. However,
it'd be useful to require the transport be specified only if the same
name would mean different things for different transports. Do we ever
see that happening?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAktLPlsACgkQE5f5cImnZrvfwQCeO6PDaK0DioHf9skYZ712o9ko
zlsAoPowEdWWlSh2m8hBNLEvX+eF4NSu
=93WG
-----END PGP SIGNATURE-----