---------- Forwarded message ----------
From: Alexey Melnikov <alexey....@isode.com>
Date: Wed, Jan 12, 2011 at 6:01 AM
Subject: Request for review of the draft describing about: URIs
To: Robert Sayre <say...@gmail.com>
Hi Robert,
Can you or one of your co-workers review
<http://www.ietf.org/id/draft-holsten-about-uri-scheme-06.txt> and make
sure that it is Ok and matches what Mozilla is doing?
Thanks,
Alexey
--
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
> ---------- Forwarded message ----------
> From: Alexey Melnikov <alexey....@isode.com>
> Date: Wed, Jan 12, 2011 at 6:01 AM
> Subject: Request for review of the draft describing about: URIs
> To: Robert Sayre <say...@gmail.com>
> Hi Robert,
> Can you or one of your co-workers review
> <http://www.ietf.org/id/draft-holsten-about-uri-scheme-06.txt> and make
> sure that it is Ok and matches what Mozilla is doing?
The spec is pretty loose, so it's mostly ok. There are two differences
from what we implement that I can see:
1) Section 5.3:
Applications SHOULD resolve unrecognized "about" URIs in the
same way as "about:blank".
We treat unknown about:* as unparseable URIs. I think we want to keep
that behavior, honestly. That's allowed by the SHOULD, but I'd like to
understand why this is a SHOULD and not a MAY, not to mention why it's
there at all.
2) Section 6:
For example, "about:blank", "about:blan%6B" and "about:blan%6b"
are equivalent
In our code they are not. The string after ':' is treated as a literal
string; when looking up about modules, so the second and third URIs
above are treated as unparseable by us. We could consider changing
this, but there are some security implications to doing that (certainly
we'd need to audit some security code).
And the same section says:
Similarly, "about:blank%3F" is not equivalent to "about:blank?".
which actually makes me wonder how one is supposed to know what _should_
get unescaped and what shouldn't..... I would really rather there were
no random equivalences here other than bitwise comparison.
-Boris