Re: On IETF policy for protocol registries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 1/20/2016 3:05 PM, John C Klensin wrote:
> Joe,
> 
> A question just to try to understand your position...
> 
> --On Wednesday, January 20, 2016 14:41 -0800 Joe Touch
> <touch@xxxxxxx> wrote:
> 
>> - those which are not services, but are duplicates of HTTP
>>
>> 	these are the "I really wanted port 80, but it's already
>> 	taken, but I need to run my own web server so users can
>> 	open a browser window to see how to monitor or configure
>> 	my device"
>> ...
>> What we really need is a way for many interfaces to be able to
>> "register" with their local web server, to reserve URL
>> prefixes, etc.

So here's the issue:

	There are two reasons people want to use HTTP:

	1) they want to run a webserver

	2) they want a framing protocol over TCP

#1 occurs because you want to really run a webserver, or because you've
decided that a webserver/client are a quicker way of writing a remote
management console, e.g., for a printer, home router, etc.

#2 occurs because you either want to just use HTTP framing because there
are existing generation and parsing tools, or because you're developing
something called a "web service" - which, IMO, are a lot like
subroutines you can call from HTTP.

---

Requests for assigned ports for #1 are commonly rejected because they
duplicate ports 80/443. It's really one service - generic web server,
which is being used for different purposes.

Requests for assigned ports for #2 are commonly approved because framing
isn't the issue; the issue is whether the service has a distinct
protocol that doesn't replicate an existing service. Consider that both
HTTP and telnet both use ASCII encodings, but HTTP is a different
service because the language is restricted, the semantics are different
etc. That's what's sought by reviewers.

------

That said, I'm not entirely sure what .well-known is needed for. I'm now
beginning to understand it might be for web services, not for duplicate
uses of generic web servers.

>> This is not at all related to services over HTTP.
> 
> It sounds to me that what you are looking for would be satisfied
> by something resembling 
> 
>    http://Domain.example.com<d>service/...
> or
>    http<d>service://domain.example.com/...

A little. It's like having a service name that can be parsed or
automatically generated - which is closer to http<d>service, AFAICT.

> (where <d> is some appropriately-chosen delimiter) as contrasted
> with 
> 
>    http://domain.example.com:port/
> 
> which, by your reasoning as I understand it (and fwiw, by mine)
> is basically a bad idea.

I don't think it's a bad idea. I think allocating a new assigned port
for this purpose is a bad idea. You can run whatever service on whatever
port you want - either by mutual agreement with the other endpoint or as
indexed by mDNS records.

What I don't like is assigning port after port after port for vendors
who want to use web browsers to access their devices configuration and
control interface. Yes, there's a problem if many system entities want
to 'register' web pages for remote access with a single web server, but
that's not a port number problem. That's a web page registration problem.

> If one ignores for the moment the differences in difficulty of
> fitting them in as extensions to the URI spec (RFC 3986) the
> first two examples are assumed to be semantically equivalent or
> what we used to call syntactic sugar.  The definition of
> <service> would ultimately depend on the domain, not some
> necessary global convention although standardization of names
> would help prevent confusion and duplication.  But, in any
> event, they would be service names, not different port numbers
> for the same protocol.

Yes, but as I noted, X over HTTP where X is a custom protocol or service
is already eligible for its own port number, and we do that a lot already.

Joe


> 
> Is that understanding correct?
> 
>      john
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]