- From: Darren New <dnew@sgf.fv.com>
- Date: Tue, 20 Jun 1995 17:40:25 +0100
- To: Martijn Koster <m.koster@nexor.co.uk>
- Cc: Ted Hardie <hardie@merlot.arc.nasa.gov>, Brian Behlendorf <brian@organic.com>, peterd@bunyip.com, rating@junction.net, www-talk@www10.w3.org, uri@bunyip.com
> first of all thanks for your summary, and for putting the > discussion back into a constructive sphere. Ditto. > My suggestion of using a KidCode HTTP header didn't provoke much > response, while I think it has some advantages: the user gets the > choice, Choice of what? > it scales, it can be added to exisiting code easily, Only if you own the source to the server. What about all the people running netscape's server (who I don't think get the source, tho I may be wrong). What about all the sites on netcom? > scales, You said that. ;-) > doesn't require a third party infrastructure, and will be quite easy > to establish as a standard since it is a simple extension to http. Well, given we can't even get over this hump, what to put in the header is still going to take work, or someone would already have done it. :-) Seriously, I think it is important that protection apply to FTP as well. I see many public providers whose web links point into FTP addresses; i.e., there are many ISPs whose web sites are built entirely in their FTP space. *I* think it's important because our stuff is accessible via FTP as well as WWW. :-) I imagine the people making entire internet packages (internet in a box, etc) would be happy to put the same code in FTP as in WWW. It also has the advantage that you don't fetch 200K of dirty picture only to be told you can't have that. You could even imagine a browser in KidCode mode not even making hotlinks on the page for the eeevil pictures. --Darren
Received on Tuesday, 20 June 1995 17:43:36 UTC