Subject: Re: Last Call: <draft-holsten-about-uri-scheme-06.txt> (The 'about' URI scheme) to Proposed Standard

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 15 Jun 2011 12:07:03 +0300

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Jun 2011 12:13:09 +0200

On 2011-06-15 11:07, Mykyta Yevstifeyev wrote:
> ...
>> configuration. Changing this has some security implications that would
>> require careful auditing of not only Gecko code but some
>> 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
> 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
> ...

I agree that not treating them as equivalent is a bug.

That being said, if our Mozilla friends do not want to fix this it might 
be a good idea to warn readers that certain implementations fail to 
properly unescape, thus it's unwise to rely on that behavior (why would 
you anyway?).

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 15 Jun 2011 18:05:33 +0300

15.06.2011 13:13, Julian Reschke wrote:
> That being said, if our Mozilla friends do not want to fix this it 
> might be a good idea to warn readers that certain implementations fail 
> to properly unescape, thus it's unwise to rely on that behavior (why 
> would you anyway?).
I fully agree with you, Julian.  I think we'll do certainly as you 
propose, unless Boris will provide some strong reasons to do in other way.

Mykyta

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Jun 2011 16:16:44 -0400

> >might be a good idea to warn readers that certain implementations
> >fail to properly unescape, thus it's unwise to rely on that
> >behavior (why would you anyway?).

If I am reading the document and the above correctly, then you are
proposing the following:

    1.  The document proposes to make standard rules about what
    applications do with input that is, by definition, completely
    internal to that application; and,

    2.  You propose in addition to state what is the standard, but
    note that nobody should rely on it because one of the largest
    implementers of the scheme doesn't follow the supposed standard.

Do I have this correct?  If so, I would like to request that the
WINDMILL or perhaps TILT WG be chartered to deal with this manner of
work.

More substantively, I fail to understand how this specification
proposes to create a class of "reserved" about: URIs when the about:
scheme seems to be internal information to an application.  I think
the Security Considerations section doesn't address any of that, and
probably ought to, particularly in light of the proposal to add text
that users ought not to depend on "standard" behaviour.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Lachlan Hunt <[email-masked]>
Date: Thu, 16 Jun 2011 10:59:26 +0200

On 2011-06-15 17:59, Boris Zbarsky wrote:
> On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote:
>> Gecko.
> No, it's to propose abandoning normalization because it's not
> necessarily compatible with existing deployed uses of about:, not
> clearly compatible with the web security model, and because the
> normalization is not defined in the spec. The Gecko behavior is just an
> illustration of the first point.
>
>> The purpose of our draft is to give a stable specification of the
>> scheme
>
> Yes, this is fine.
>
>> and normalize all existing types of behavior with regard to

Mykyta, we do need to make this spec document reality, particularly 
where implementations are unwilling to make changes.  If it doesn't do 
that, then the spec is useless.  I will be reviewing the options and 
look into exactly how other browsers handle these cases, and make 
appropriate changes to the spec.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jun 2011 11:14:20 +0200

On 2011-06-16 10:59, Lachlan Hunt wrote:
> that, then the spec is useless. I will be reviewing the options and look
> into exactly how other browsers handle these cases, and make appropriate
> changes to the spec.

On the other hand, you're trying to define a URI scheme. If it's 
handling conflicts with the base URI spec, that's a bug. Period. You may 
*document* that some UAs have this bug, but you can't change it to be 
not a bug.

Best regards, Julian

---

From: Lachlan Hunt <[email-masked]>
Date: Thu, 16 Jun 2011 11:20:14 +0200

> *document* that some UAs have this bug, but you can't change it to be

Theoretical purity is not a priority for the specs I edit.  Wilful 
violations of other specs where necessary are acceptable.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jun 2011 11:35:59 +0200

> violations of other specs where necessary are acceptable.

Lachlan, with all due respect, I really do not care what *your* 
priorities here are.

If you define a URI scheme, you'll have to be consistent with URI 
syntax. There's really no wiggle room except for warning about 
implementations that may not do it right.

Best regards, Julian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Jun 2011 10:15:07 -0400

The question is what "necessary" means in terms of willful violations of 
specs.  There are at least three cases I can understand, with different 
implications:

There are cases where the existing spec, while it claims to apply, 
actually is a bad idea.  Then we need to document the problem and the 
solution, and make sure the community agrees to the change.  This 
happens.  It usually results in an "updates" indication in the new spec, 
so folks know that the old one is not complete.

There are cases where a spec is documenting existing practice.  IIt can 
document that practice is different from the spec.  It has to do so 
while carefully being clear that the standards should apply, and that 
the practice does not match.  It is often useful to discuss the reasons 
for the mismatch.

Then there are cases where folks are attempting to standardizea space 
that has been unclear, under-specified, or a mess, and much of the space 
does not comply with the specs.  That is NOT a good reason to 
standardize non-compliant behavior.

I can not tell which of those you mean when you say that "Willful 
violations of other specs where necessary are acceptable."

Yours,
Joel

---

From: Boris Zbarsky <[email-masked]>
Date: Wed, 15 Jun 2011 11:59:02 -0400

...

> I don't think MAY is fine here, as this is a recommendation.

I'm questioning it being a recommendation, is the point.  Why is this 
behavior recommended, exactly?  Given lack of existing interop and lack 
of a MUST-level requirement here, the only reason for a SHOULD would be 
if the behavior is believed to be better than other alternatives, right? 
  Is it?  I don't see why.

Yes, this is fine.

> behavior rather than for other apps to do this.

That's not clear to me given the security implications.  Do you have 
data to back this up?

> regarding your January comments/insist on incorporating them in the draft.

See above.

-Boris

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 17 Jun 2011 06:30:48 +0300

> implementations that may not do it right.
Please note that we're trying to produce the specification of the scheme 
which is used internally by the browsers.  Thus, it is almost impossible 
to consider all existing behavior of all existing browsers.  In order to 
avoid such situation as we currently have with Gecko, when an 
application is known to fail to satisfy one of the regulations of the 
Standards Track document, I think we could make the document 
Informational, which will specify "the most common" practice while 
mentioning some other "non-common" behavior.  In this way we will fail 
to "standardize" the scheme, but at least won't create a lot of 
conflicts, which, IMO, is more important.

As for the normalization of the about URIs.  They are a subject to RFC 
3986, being URIs, and are a subject to its normalization rules.  Making 
an exception for them isn't an option, I think.

Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 17 Jun 2011 06:48:25 +0300

>      implementers of the scheme doesn't follow the supposed standard.
Currently and actually I have nearly the same concern.  The -02 version 
still had Informational intended status, I don't know what was a reason 
for switching to Standards Track.  I have a feeling that producing the 
Informational RFC describing "the most common behavior" is an option, 
but we'll fail to "standardize" the scheme.  I personally think 
standardizing the internal-usage scheme is a bit irrelevant, so here i 
agree with you.
> that users ought not to depend on "standard" behaviour.
That's an interesting point as well.  Trying to standardize the abut URI 
scheme, we're trying to state that URI about:nnnn is used only and only 
fir the purpose xxxx whereas about:mmmm is used only for purpose yyyy.  
I understand your concern regarding different purposes of one about URI 
in different apps.  I can share it with you as well.  As a result, 
abandoning the intends to give the scheme a Standards Track 
specification and complete revision of regulations with regard to 
resolving about URIs may be an option.

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Fri, 17 Jun 2011 00:01:05 -0400

> that users ought not to depend on "standard" behaviour.

Yes... I'm actually very confused about the point of this document.
It's documenting a URI scheme that's used ONLY internally, and,
therefore, has no interoperability requirements.  As best I can tell,
the issue here is to let browser makers know what other browsers do,
so that maybe new browsers will decide to do the same things.  That's
fine, and that helps users have a consistent experience across
browsers.  But it strikes me as Informational, not Standards Track.
MUSTs and MUST NOTs seem completely out of place here, to me.

If different browsers exhibit different behaviour with the same
about:xxxx URI, that's as it is, and the variations should be
documented.  Developers of new browsers will have to decide which
older browsers to emulate.

But none of this actually speaks to interoperability among browsers or
web servers or applications or....

Barry

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 17 Jun 2011 07:03:02 +0300

16.06.2011 11:59, Lachlan Hunt wrote:
>> necessarily compatible with existing deployed uses of about:,
Probably.  Because of this in my previous messages I proposed abandoning 
making the spec. Standards Track.
>> not
>> clearly compatible with the web security model,
How?
>> and because the
>> normalization is not defined in the spec. 
Normalization is defined in RFC 3986.
>> The Gecko behavior is just an
But see above.
> where implementations are unwilling to make changes.
I agree; but different existing behavior makes this impossible.  We 
can't list everything which is currently supported by all 
implementations in the Standards Track document, but we can do this in 
the Informational.

Mykyta
> If it doesn't do that, then the spec is useless.  I will be reviewing 
> the options and look into exactly how other browsers handle these 
> cases, and make appropriate changes to the spec.
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Jun 2011 21:37:54 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, June 16, 2011 9:01 PM
> To: Andrew Sullivan
> Cc: [email-masked]; IETF Discussion;
> Julian Reschke; Boris Zbarsky; Alexey Melnikov
> Subject: Re: Last Call: <draft-holsten-about-uri-scheme-06.txt> (The
> 'about' URI scheme) to Proposed Standard
> 

I suppose adding it as an IANA-registered scheme, referencing something that's Informational, is a reasonable way for a new browser implementer to be reminded that support for such a scheme is common and probably expected.

But if we feel that's either not useful or not the IETF's place (or not a valid use of the IANA scheme registry), then I'm left to +1 Barry's comments above.

-MSK

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Jun 2011 08:51:49 +0200

> web servers or applications or....

The reason this whole activity is started is...

   <http://www.w3.org/TR/2011/WD-html5-20110525/syntax.html#the-doctype>

which "defines"

   about:legacy-compat

for which interoperable behavior is required from browsers.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Jun 2011 08:53:50 +0200

> I suppose adding it as an IANA-registered scheme, referencing something that's Informational, is a reasonable way for a new browser implementer to be reminded that support for such a scheme is comm…

Optimally, we had a strategy by which we can reserve certain scheme 
names (*), although they aren't really interoperable nor have a proper spec.

Best regards, Julian

(*) about, chrome, itms, ical, and probably many more...

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Jun 2011 08:57:30 +0200

Hi Barry,

On 6/17/11 6:01 AM, Barry Leiba wrote:
> therefore, has no interoperability requirements.

Indeed.  That's a good argument to stop right there.

>   As best I can tell,
It seems to me we could simply inform IANA that about: is reserved for
internal use by a browser, and not to be assigned for other purposes,
and not to be exchanged between hosts.  Do we really need an RFC to do that?

Eliot

---

From: Lachlan Hunt <[email-masked]>
Date: Fri, 17 Jun 2011 13:25:26 +0200

On 2011-06-17 06:32, Boris Zbarsky wrote:
> On 6/17/11 12:03 AM, Mykyta Yevstifeyev wrote:
>>>> not
> "about:blank" in particular is magic with respect to security on the web
> in various ways (e.g. it can end up same-origin with http:// pages). So
> I think we do need to specify exactly when this magic security behavior
> takes place.

The spec is not meant to imply that the special same-origin behaviour 
for about:blank is to be inherited by any other about URI, even if other 
URIs also return a blank document.  Perhaps, I need to make that clearer 
in the spec.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jun 2011 09:32:44 -0400

>>>>> "Barry" == Barry Leiba <[email-masked]> writes:
    >> proposes to create a class of "reserved" about: URIs when the
    >> about: scheme seems to be internal information to an
    >> application.  I think the Security Considerations section doesn't
    >> address any of that, and probably ought to, particularly in light
    >> of the proposal to add text that users ought not to depend on
    >> "standard" behaviour.

    Barry> Yes... I'm actually very confused about the point of this
    Barry> document.  It's documenting a URI scheme that's used ONLY
    Barry> internally, and, therefore, has no interoperability
    Barry> requirements.  As best I can tell, the issue here is to let

It does.  It's an RFC1918-type use, and for the same reason we had to
document those networks, we have to document this URI.
This document prevents someone else from creating "about:" scheme which
is NOT internal.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 17 Jun 2011 09:44:12 -0400

> This document prevents someone else from creating "about:" scheme which

Oh, yes: to be clear here... I am NOT suggesting that we shouldn't
register the URI scheme.  I'm only saying that the registration
doesn't require a great deal of standards-track documentation.  A
short Informational doc should do.

Barry

---

From: Boris Zbarsky <[email-masked]>
Date: Thu, 16 Jun 2011 12:08:42 -0400

On 6/16/11 4:59 AM, Lachlan Hunt wrote:
> where implementations are unwilling to make changes

To be clear, in the normalization case we (Gecko) may be willing to make 
changes, but not if it causes conflicts with existing security 
assumptions on the web.  And that's something that needs to be 
investigated _before_ this spec if finalized, clearly.

-Boris

---

From: Boris Zbarsky <[email-masked]>
Date: Fri, 17 Jun 2011 00:32:13 -0400

The question is what existing UAs do and what assumptions web authors 
make, as well as what assumptions should be safe for them to make.

Note that "not clearly compatible" doesn't mean "not compatible"; it 
just means it needs sorting out.

Note that this is also an exception to the general claim that about: is 
only used internally.   That's not the case for about:blank.

So I think we do need a Standards Track document that pins down how 
about:blank works; I will be happy to make whatever changes are needed 
to Gecko here to achieve interop assuming that the result has been 
vetted in terms of the security implications.

For other about: URIs, I don't know whether Standards Track necessarily 
make sense.

> Normalization is defined in RFC 3986.

Browsers don't actually implement RFC 3986 in practice because it's not 
compatible with web content, last I checked....  Pretending like they do 
doesn't seem to be productive.

Or is the point that the algorithms to be used are just the ones defined 
in 3986 and those are sufficiently ok that browsers do actually use 
them?  That wasn't clear to me from the current draft.

-Boris

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Jun 2011 18:14:26 +0200

> doesn't seem to be productive.

It would be very helpful for the IRI WG if browser vendors actually 
reported what this incompatibility is; and whether UAs indeed agree on 
what the "right" thing to do is.

So far I'm aware of certain kinds of preprocessing, and workarounds for 
specific schemes like "data" and "file", but that's it...

Best regards, Julian

---

From: Boris Zbarsky <[email-masked]>
Date: Fri, 17 Jun 2011 12:53:51 -0400

> URIs also return a blank document. Perhaps, I need to make that clearer

Yes, but is it meant to be inherited by "about:blan%6b" ?  That's the 
issue that needs sorting out in terms of normalization, for example.

The current spec draft explicitly says that "about:blan%6b" and 
"about:blank" are equivalent.

I just did some testing on that, since it looks like it won't happen 
otherwise.  You can see the testcase I used at the end of the mail. 
Results are:

Gecko all versions: URI not loaded at all
Chrome 11 stable: document URI is still shown as escaped,
                   security magic is done
Chrome 14 dev: same as Chrome 11 stable
WebKit tip: same as Chrome 11 stable
Safari 5: same as Chrome 11 stable
Opera 11.11: URI not loaded at all (or at least the subframe's load
              event doesn't fire).
IE9: Loads error page in the subframe and alerts an access denied error.
      This is the same in stadards, IE8, IE7, and quirks modes (though
      the textual representation of the error varies).

I didn't bother testing older Opera versions; if someone cares please 
feel free to do so.

Note that some browsers have behavior that differs between iframes and 
the url bar.  For the url bar, I observe the following behaviors for 
"about:blan%6b":

Firefox all versions: alert saying the URI is invalid and cannot be
                       loaded.
Chrome 11: URL bar shows "about:blank", content area shows a blank
            document.
Chrome 14: redirects to chrome://blank which then gives an "invalid
            URI" error page
WebKit tip: URL bar shows "about:blan%6b", content area shows a blank
             document.
Safari 5: As WebKit tip.
Opera 11.11: Redirects to "opera:blank" which gives an "Invalid address"
              error page.
IE9: URL bar shows "about:blan%6b" and an error page is shown.

So it could be argued that Chrome 11, WebKit tip, and Safari 5 do what 
the spec currently calls for.  No other browser does.  And Chrome 14 is 
inconsistent in how it handles this URI depending on the context it's 
encountered in.

-Boris

Testcase:

<!DOCTYPE HTML>
<body>
   <iframe id="iframe"></iframe>
   <script>
     var i;
     onload = function() {
       i = document.getElementById("iframe");
       i.onload = function() {
         try {
           alert(this.contentDocument.documentURI);
           alert(this.contentDocument.documentElement);
         } catch(e) { alert(e); }
       }
       i.src = "about:blan%6b";
     }
   </script>
</body>