Re: [apps-discuss] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.txt

[Frank Ellermann <[e-mail]>]

On 16 July 2011 09:57, "Martin J. Dürst" wrote:

>> RFC 3986 does not explain that some unencoded US-ASCII char.s
>> are never permitted in URIs: "{" | "}" | "|" | "\" | "^" | "`"

> Well, yes, it's the spec for URIs, not for "what's not allowed
> in URIs".

Okay - but not very helpful for folks trying to "upgrade" older
spec.s based on RFC 1738 to something based on RFC 3986/3987, or for
developers trying to filter completely bogus URIs.

The older RFCs had a nice <uric> rule for this purpose.  My list
above was incomplete, I forgot (at least) "<" / ">" / SP / DQUOTE

> That "[" / "]" can only be used for IPv6 addresses and the like
> is definitely somewhat inconsistent. If there ever were an
> update of RFC 3986, I can imagine that to be changed (but that's
> only a guess).

For the pseudo-<path> in news://server/message-ID URIs that was
an obstacle.  But now I'm curious, there is no <path> in mailto:,
and that could allow square brackets in mailto: IPv6 literals...

Yes, RFC 6068 explicitly allows "[" ... "]" in a <domain>, good.

 [about RFC 5147]
> Does that mean that it's implemented in Firefox and Opera?

FF5 test with <http://www.postel.org/ien/txt/ien111.txt#line=1483>

No, sorry.  No opera on my box, that will be my last resort if I'm
ever annoyed with IE + Chrome + FF at the same time.  But I read
AvK's blog, just in case.

> For Chrome, you could submit a bug or patch to webkit, I guess.

Chromium issue 77024, waiting for "confirmation" since March.  For
IE9 a very complete issue report was closed as "not reproducible",
and I concluded that the IE9+ developers are not too interested
in contributions from IE9+ users.

-Frank