Re: TFTP URL

From:  Mark Baker <distobj@acm.org>
Message-Id:  <200111232029.PAA21973@markbaker.ca>
Date:  Fri, 23 Nov 2001 15:29:49 -0500 (EST)
In-Reply-To:  <5.1.0.14.2.20011123075123.031c8eb0@brandenburg.com> from "Dave Crocker" at Nov 23, 2001 08:01:36 AM

>...
>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?
Think a bit about the "mailto:" scheme. Think about the "http:". 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?

>MB
>-- 
>Mark Baker, Chief Science Officer, Planetfred, Inc.
>Ottawa, Ontario, CANADA.      mbaker@planetfred.com
>http://www.markbaker.ca   http://www.planetfred.com

I understand trying to block creation of brain dead protocols. I find
it absurd to try to block the creation of a name in the increasingly
popular URI name space for an exsting used and deployed standardized
IETF protocol which is already named in other spaces such as port
number and IANA protocol name, even if it is brain dead.

For people worried about somehow "encouraging" TFTP, I'd be fine with
whatever kind of evil status you want, like "NOT RECOMMENDED" or
making the RFC Informational instead of standards track or even
perhaps bizarreness like saying the "tftp:" scheme is reserved because
it is usually used for TFTP as described in the draft but not formally
allocating it to TFTP. But the URI scheme that is being used for the
IETF standarized TFTP protocol should be recongized.

Donald

Received on Sunday, 25 November 2001 00:46:41 UTC