On 09/30/2010 08:36 PM, Drake Wilson wrote: >> This release features "tor://" and "tors://" urls that will >> automatically enable Tor before loading the corresponding http or >> https url. >> > Ick. This sort of layer-mixing is the sort that forces people to use > a certain protocol for no actual reason. > ... > Is there a reason not to use something like tor+http and tor+https for > the schema, thus opening up the space for (as a facetious example) > tor+nntp or analogous usages later? >
Drake is correct, I don't think that scheme transport swap method is a great idea. That being said, the ability to bookmark a site securely is advantageous. Plus, relative URL's referenced on a host would inherit the scheme. Based on: http://labs.apache.org/webarch/uri/rev-2002/rfc2396bis.html#scheme I agree that tor+scheme or tor.scheme would be a better nomenclature. It appears that +, _ and . can be used as separators. For example: tor.mailto:u...@someplace.org could use an SMTP anonymizer. I do understand why it was implemented this way. Scheme stacking would be much more difficult to pull off given current browser technology. To the best of my knowledge, there are no browsers that would easily support this. If you could specify tor.* as a scheme and that scheme would launch tor, set the proxy in the browser and then reprocess with the rvalue recursively then this would be feasible However, it would require non-trivial customization of the browser. I can think of other uses for this such as blind.http:// that would launch a non-visual accessibility browser. Then the visually impaired user could access anonymously using: tor.blind.http:// Someone needs to write a 'scheme stacking' URI extension RFC. --Dave *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/