Hello Boris, all,
FYI, authors of draft-holsten-about-uri-scheme allowed me to become the
co-author of this draft. We got to your message. The -07 is almost
prepared for publication, but Lachlan pointed these comments were not
addressed. Let me express my opinion regarding them.
22.01.2011 7:02, Boris Zbarsky wrote:
There seem to be two differences between what the draft specifies
right now and what Gecko, at least, does:
1) Section 5.3 says:
Applications SHOULD resolve unrecognized "about" URIs in the
same way as "about:blank".
Gecko treats unknown about:* as unparseable URIs, and is not likely to
change that behavior. While that's allowed by the SHOULD, it's not
clear to me why this is a SHOULD as opposed to a MAY, nor is it clear
why this is present at all. In particular, as specified this will
cause situations where an empty resource is silently returned instead
of a failure that the consumer can notice (e.g. in the DOM case via
error event handlers and the like).
I don't think MAY is fine here, as this is a recommendation. Moreover,
as Gecko seems to be an only browser with such behavior, I don't think
changing the Standards Track specification should mention/change this;
as you noted, SHOULD is not a restriction.
2) Section 6 says:
For example, "about:blank", "about:blan%6B" and "about:blan%6b"
are equivalent
In Gecko they are not. The string after ':' is treated as a literal
string; when looking up a way to handle the URI the second and third
URIs above are treated as unparseable by Gecko in its default
configuration. Changing this has some security implications that
would require careful auditing of not only Gecko code but some
specifications (e.g. HTML5 defines certain special-case security
behavior for about:blank that's not obviously safe to apply to the
other strings above).
The same section says:
Similarly, "about:blank%3F" is not equivalent to "about:blank?".
which I think is trying to explain by example that only unreserved
characters need to be unescaped. But that assumes an implementation
of RFC 3986 which may or may not be the case in web browsers (and is
NOT the case in Gecko, for example, for various web-compatibility
reasons). Unless there are very strong reasons for it, I would
recommend that no normalization is performed on about: URIs, period.
The point of this comment is to propose abandoning normalization of
'about' URIs because of some ad hoc behavior of an only application -
Gecko. The purpose of our draft is to give a stable specification of
the scheme and normalize all existing types of behavior with regard to
handling 'about' URIs. It will be easier for Gecko to change its
behavior rather than for other apps to do this.
Boris, could you please let me know whether you have some strong opinion
regarding your January comments/insist on incorporating them in the draft.
Thanks,
Mykyta Yevstifeyev
-Boris
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf