Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt

[t.petch <[e-mail]>]

----- Original Message -----
From: "Sam Ruby" <[e-mail]>
To: "Matthew Kerwin" <[e-mail]>
Sent: Sunday, January 04, 2015 1:32 PM
> On 01/04/2015 07:22 AM, Matthew Kerwin wrote:
> >
> > On 2 January 2015 at 00:21, Sam Ruby <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     A few concrete examples are here:
> >
> >
http://www.ietf.org/mail-__archive/web/apps-discuss/__current/msg13511.h
tml
> >
<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13511.html
>
> >
> >     It is my hope that by comparing notes we can converge.
> >
> > ​To be honest, a big reason for using RFC 3986 as a normative
reference
> > is so I don't have to deal with things like hostnames. If those
> > definitions are good enough for the shiny new HTTP/1.1 (which
actually
> > uses hostnames) then surely they're also sufficient for file: (which
> > often doesn't).
> >
> > BTW who on earth writes localhost as "2130706433"? Or more
> > significantly, who on earth *accepts* that as a valid URL?
>
> I cited three specific examples in:
>
>
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13511.html
>
> All three of the below are accepted by Chrome, and possibly others:
>
> file://2130706433/foo
> file://[2001::1]/foo
> file://０Ｘｃ０．０２５０．０１/foo
>
> Note that RFC 3986 requires square brackets around IPv6 names, but
your
> draft does not.  The final example involves IDNA processing.
> Unfortunately, IDNA processing can't be avoided, nor does RFC 3986
> specify it.

Sam

I part company with you here.  IDNA processing can be avoided - don't do
it!

Many of the IETF standards have no i18n in general, or IDNA in
particular, just as the early standards' views of security would have
hackers licking their lips with glee.

Retrospectively, security has been added to most protocols, i18n has
been added to many.  The lack of security is a show stopper for most,
but the lack of i18n limits the scope but still renders it useful for
many so Matthew's I-D I see as a good step forward, all it needs to say
is on this is that i18n (or IDNA) is for further study and we would
still have a valuable RFC.

I note that kitten is currently wrestling with normalisation in the
context of Kerberos, where a loophole could generate a major security
breach, and seem to be heading towards saying, if you are not an expert
in this area, do not attempt to implement it (my words) i.e. this
i18n/IDNA/normalisation area is not well enough engineered to be relied
on in some areas.

Tom Petch

<snip>