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


From: John C Klensin <klensin@jck.com>
Date: Wed, 21 Nov 2001 03:45:13 -0500
To: Martin Duerst <duerst@w3.org>, discuss@apps.ietf.org
Message-ID: <133130545.1006314313@P2>

--On Wednesday, 21 November, 2001 16:37 +0900 Martin Duerst
<duerst@w3.org> wrote:

> I don't have much to add here, except to very clearly point
> out that URIs are about much more than only 'just click here'.

Of course.  But we have claimed for years that the default
answer to a request for a new URL/URI type is, in the absence of
justification, "no" .  And the only justifications that are
apparent for this one are "just click here" and, more
importantly, "make it a bit more convenient to specify what goes
into a configuration file".   I don't consider either, in
itself, to be adequate.

Moreover, in most configuration file contexts with TFTP (or
anything else for that matter), one of the following is true:

(i) The config file entry is going to be a TFTP reference and
anything else is invalid.  In that case, use of a URI provides
not extra advantages other than appearing to be "modern"
(another reason I don't find persuasive).

(ii) The entry can be a general URI (or even URL), or will be
interpreted that way.  This strikes me as a good way to get into
trouble when files are executed in the background, as config
files usually are.  It is probably even a security risk that
should be documented with each impacted config file.  

And, of course, if the first case is intended, but someone does
a bit of shortcut programming and says "aha, this is just a URL,
call the general URL processor", a really neat set of exploit
attempts opens up.  So, again, if this thing is to go through, I
suggest the security considerations section be strengthened.  A

Received on Wednesday, 21 November 2001 03:46:00 UTC

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