I think the URI proposal is an excellent way to allow a Web Service to
be identified by means of just a DNS name. So instead of specifying
http://wev.google.com/_well-known/wev, someone can just type
'google.com' into their wev client and it works.
It is not a good match for resolving http URLs but it is a good way to
resolve a raw dns name and a service identifier to a web service
That said, how does a Web service using the URI scheme tell clients
that the service is available via http/1.1 or http/2.0 so that it can
select the appropriate host and port first time?
It would be rather useful to have http2: and http2s: defined as URL
schemes for 'this really has to run over http2, don't try anything
else, just do it', ditto for http1 and http1s and have http:, https:
be used for 'try what works'.
http2 is not a scheme people should use as a regular thing, it should
only be used when the distinction between http1 and http2 really
matters. For example, when the Web site is only available on http2 and
http1 is not supported or for debugging Web sites or to enable
negotiation of the protocol version whether via SRV or some other
On Mon, Aug 20, 2012 at 3:00 PM, Ted Hardie <ted.ietf@...> wrote:
> On Mon, Aug 20, 2012 at 10:39 AM, Eliot Lear <lear@...> wrote:
>> Reasonable? Yes. Best course of action? I don't know. I know I'm
>> beginning to sound like a broken record, but I don't know if SRV is the
>> right record for the job. For one thing, if you use another record, you
>> can use that same optimistic approach for an explicit port in the URI.
>> Of course, then there is the added implementation headache of a new
>> record. We've gotten around that elseewhere with TXT records, but I
>> don't recommend it here.
> Do you mean to suggest something like
> http://tools.ietf.org/id/draft-faltstrom-uri-06.txt ?