- From: Mark Baker <distobj@acm.org>
- Date: Sun, 25 Nov 2001 01:26:36 -0500 (EST)
- To: dee3@torque.pothole.com (Donald E. Eastlake 3rd)
- Cc: discuss@apps.ietf.org
> >IMO, all URIs should be able to be resolved safely, and therefore TFTP > >shouldn't get its own scheme. > > That's absurd. Are there any schemes it is always safe to resolve? Many (likely most - it would be interesting to do an analysis) are. Some are not. > Think a bit about the "mailto:" scheme. Typically pops up a new outgoing email box. Quite safe (it doesn't send the email). > Think about the "http:". Invokes GET, which is safe. Yes, an app developer is free to implement unsafe GETs, but any bad stuff that happens is the fault of that developer, not the person doing the GET. > I'm > sure someone will even implement the "data:" scheme so that it suffers > from buffer overflow although I guess a proper implemention of it > along with a few others like "mid:" and "cid:" could be safe... Right. > If you are going to tell some application level protocol filter to NOT > do TFTP and it takes arguments in URI syntax, how are you going to > express TFTP? This is a problem? Anyhow, I'm not rabidly anti-TFTP URI scheme. It could be argued that TFTP, by its nature, should do retrieval safely, and that its RFC not saying so doesn't matter. I'm not familiar with current practice. Do any known TFTP servers do unsafe retrievals? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Sunday, 25 November 2001 01:29:19 UTC