Re: On IETF policy for protocol registries

[Joe Touch <[e-mail]>]

On 1/19/2016 12:32 AM, Eggert, Lars wrote:
> Hi,
> 
> On 2016-01-18, at 23:07, Phillip Hallam-Baker <[e-mail]> wrote:
>>
>> It is natural for the client resolving [e-mail] to use the
>> following Web Service Endpoints:
>>
>> http://host1.example.com/.well-known/mmm/
>> http://host2.example.com/.well-known/mmm/
>>
>> In effect we are providing the SRV prefix to the HTTP server using the
>> URI request line in the same way that we use the Host: header to tell
>> the server which service is being accessed (example.com in either case
>> as following the prcedent set for CNAME lookup. we give the original
>> DNS query name, not the internal DNS translations).
> 
> as a reviewer for the ports registry, we frequently see requests for
> port assignments for services over HTTP/HTTPS where the applicant states
> that port 80/443/8080/etc. are already "taken". So they want to be able
> to use URLs with a fixed port other than those.

Some context on these requests:

They typically fall into two categories:

1) I want to run a configuration system, monitoring system, etc. using
existing web interfaces

2) I have a completely custom protocol that happens to be encoded over
HTTP/HTTPS

#2 is no different than X over SOAP, etc. That's just another encoding,
and is a separate service.

#1 is the difficulty. It becomes nearly impossible to determine how this
is a distinct "service" from ports 80/443. However, there is a
legitimate need to run multiple "services" over an encoding.

There are two ways to handle this case:

	- build the differentiator into HTTP
		as Lars suggested using a new URL extension
		(which would work only for HTTP sharing)

	- build the differentiator into TCP
		see draft-touch-tcpm-sno
		which would work for any X over Y service

Joe