W3C home > Mailing lists > Public > uri@w3.org > May 2005

Re: Status of ftp:///?

From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Sat, 14 May 2005 11:15:11 +0200
To: uri@w3.org
Message-ID: <4285C19F.17EF@xyzzy.claranet.de>

Graham Klyne wrote:

> implicitly, by omission of any contrary qualification,
> permits ftp:///.

It's clear that you don't like my "let's see what happens"
approach, but with two browsers I got ftp:/// => bad, not
the same as ftp://localhost/

BTW, the same effect as for http:/// vs. http://localhost/

RfC 1738 says that file:/// is a special case, so I guess
that ftp:/// and http:/// should be plain wrong.

RfC 2396 has server = [ [ userinnfo "@" ] hostport ] for
one case of authority, but the text says "<userinfo>@" and
":port" might be omitted, not the "host".

In STD 66 that's:

|      authority   = [ userinfo "@" ] host [ ":" port ]
|      host        = IP-literal / IPv4address / reg-name
|      reg-name    = *( unreserved / pct-encoded / sub-delims )

| If the URI scheme defines a default for host, then that default
| applies when the host subcomponent is undefined or when the
| registered name is empty (zero length).  For example, the "file"
| URI scheme is defined so that no authority, an empty host, and
| "localhost" all mean the end-user's machine, whereas the "http"
| scheme considers a missing authority or empty host invalid.

You found a bug in the ftp-uri-04 draft.

Adding  'As for the "http" scheme the <host> component of the
<authority> cannot be empty'  could fix it.  Bye, Frank
Received on Saturday, 14 May 2005 09:19:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:09 UTC