W3C home > Mailing lists > Public > ietf-discuss@w3.org > November 2001


From: Mark Baker <distobj@acm.org>
Date: Sun, 25 Nov 2001 01:26:36 -0500 (EST)
Message-Id: <200111250626.BAA26050@markbaker.ca>
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...


> 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?

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC