Re: [port-srv-reg] Four final points for discussion

[Joe Touch <[e-mail]>]

On 9/17/2010 12:50 AM, Magnus Westerlund wrote:
> Joe Touch skrev 2010-09-16 18:44:
>>
>>
>> On 9/16/2010 2:11 AM, Magnus Westerlund wrote:
>>> Joe Touch skrev 2010-09-08 18:01:
>>>>
>>>>
>>>> On 9/7/2010 4:14 PM, Stuart Cheshire wrote:
>>>>> On 3 Sep, 2010, at 12:01, Michelle Cotton wrote:
>>>>>
>>>>>> I agree with all the changes below.
>>>>>> Regarding the last point, can the service name aliases for future
>>>>>> registrations go in the notes column?
>>>>>>
>>>>>> Michelle
>>>>>
>>>>>
>>>>> I don't think there will be any future aliases.
>>>>>
>>>>> I don't see any reason to be allowing further creation of aliases that
>>>>> add nothing except being a new name for something else that already exists.
>>>>
>>>> The burden falls on the owner of the port. If they want to ask for
>>>> aliases, e.g., to shift from an old product name to a new one, I can't
>>>> see why we would care. There is impact, but only on that port anyway.
>>>> However, I'd restrict it to the owner of the port only.
>>>>
>>>> A good example of this would be the STUN/TURN stuff we discussed recently.
>>>>
>>>
>>> I think we should strongly recommend against alias for the first case
>>> like http and www. However STUN and TURN are not aliases, they are
>>> compatible services that can co-exist on the same port. Thus I wouldn't
>>> call them aliases at all.
>>
>> Any time more than one string maps to the same port number it's a kind
>> of an 'alias'. The only way for the client to know the difference is via
>> in-band information.
>>
>> I.e., we would allow aliases for:
>> 	- different services
>> 	- that can be resolved in-band
>>
>> Unless BOTH of those apply, we would not allow aliases except:
>>
>> 	a) legacy (www, http)
>> 	b) to support changeover to the new namespace
>>
>
> I think we are in agreement. Are the text clear enough on this in your
> view. I think we can have it improved further to make the above clear.

I tried to do so in the text I just posted.

Joe