Re: http+srv worth its own URI scheme? (ISSUE-49 schemeProtocols-49)

On Feb 23, 2009, at 4:07 PM, Thomas Roessler wrote:

> On 24 Feb 2009, at 00:02, Cullen Jennings wrote:
>
>>> 1. Use something like SRV records.  That's probably the cleanest  
>>> solution.  If SRV lookup gets deployed on clients, then it's  
>>> likely to work equally well with HTTP and HTTPS.
>>>
>>> 2. Put a Web server on port 80 of the NAT box that supports name- 
>>> based virtual hosts and does intelligent things.  E.g., forwards  
>>> transparently depending on the Host header.  Or, redirects to  
>>> another port that then goes straight to the box behind the NAT.   
>>> This is likely to lead to some trouble with HTTPS (no good), but  
>>> should otherwise lead to reasonable behavior.
>>
>> My worry is that now the user would have to go and configure  
>> something on the NAT box - basically what domains were in use and  
>> what internal server they pointed at.
>
> So, what's the reason for that configuration to be more complex than  
> configuring DynDNS for automatic updates?  It seems strange to  
> assume that -- on the one hand -- the user should be able to easily  
> configure dynDNS to set SRV records, but -- on the other hand --  
> assume that the user isn't capable to do an equivalent amount of  
> configuration on their NAT box.

I'm assuming that there would be pretty much automatic stuff for  
DynDns and the user interface of the box supporting this would know  
how to do it. The issues is which box you need to do the configuration  
on, the box receiving the services that benefit from the configuration  
or some other box which does not. I'm trying to align incentives for  
the work being done by the box that gets the befit. For example, on  
your xbox, or you DVD player, you enter a domain name you would like  
to have at some service such as dyndns, the xbox check dnydns and  
finds the requested domain is taken but presents you with a list of  
alternatives, you pick one and it is all done.  This is much easier  
than trying to explain to users how to find and configure their  
multiple layers of NAT. Many Service providers have a NAT in the DSL  
modem which the user is not allowed to configure.

>
>
>> This is pretty similar to configuring the static port forwarding in  
>> NATs. Some technically savvy users manage to make it work but  
>> trying to explain how to do to most people is very hard so I'm  
>> trying to avoid that approach.
>
>>> Also, is there any reason to believe that http+srv would be easier  
>>> to deploy in clients than an SRV-aware version of the http URI  
>>> scheme?  (I can't think of any, but I don't claim to have thought  
>>> through every wrinkle of this proposal.)
>
>> Not really - the main difference seems to be that things that did  
>> not support the new stuff would not generate an error for http but  
>> would for http+srv
>
> I'm not sure whether you imply that that's a good thing or a bad  
> thing.  So, my question would then be:  What would the user be  
> supposed to do when http+srv causes some strange error to occur?
>


Well either way the user current software is not capable of reaching  
the desired server -  but I believe providing an error as early as  
possible about what the problem is is much better than sending people  
to the wrong website. Phishing makes the idea of going to the wrong  
server even more horrifying.

Received on Tuesday, 24 February 2009 17:51:46 UTC