On 2011-06-22 06:39, Mykyta Yevstifeyev wrote:
(1) There seems to be consensus that registering this URI as a
mechanism for accessing built-in functionality and configuration
information such as application information, preferences, or
settings. (Text derived from the Abstract with configuration
Hello all,
23.06.2011 14:16, Lachlan Hunt wrote:
On 2011-06-22 06:39, Mykyta Yevstifeyev wrote:
(1) There seems to be consensus that registering this URI as a
mechanism for accessing built-in functionality and configuration
information such as application information, preferences, or
settings.
Hello John,
Thanks for your thoughts and proposals. Please see my comments (as one
of the document co-authors) in-line.
17.06.2011 19:49, John C Klensin wrote:
Given the controversies, I decided I needed to do a careful
reading of this document. While I respect and appreciate what
the
On 6/17/11 7:25 AM, Lachlan Hunt wrote:
On 2011-06-17 06:32, Boris Zbarsky wrote:
On 6/17/11 12:03 AM, Mykyta Yevstifeyev wrote:
not
clearly compatible with the web security model,
How?
about:blank in particular is magic with respect to security on the web
in various ways (e.g. it can end
On 2011-06-17 06:01, Barry Leiba wrote:
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
On 2011-06-17 06:37, Murray S. Kucherawy wrote:
...
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.
...
Optimally, we
Hi Barry,
On 6/17/11 6:01 AM, Barry Leiba wrote:
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.
Indeed. That's a good argument to stop right there.
As
On 2011-06-17 06:32, Boris Zbarsky wrote:
On 6/17/11 12:03 AM, Mykyta Yevstifeyev wrote:
not
clearly compatible with the web security model,
How?
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
Barry == Barry Leiba barryle...@computer.org writes:
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
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
On 6/16/11 4:59 AM, Lachlan Hunt wrote:
Mykyta, we do need to make this spec document reality, particularly
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
On 6/17/11 12:03 AM, Mykyta Yevstifeyev wrote:
not
clearly compatible with the web security model,
How?
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
On 2011-06-17 06:32, Boris Zbarsky wrote:
...
and because the
normalization is not defined in the spec.
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
Given the controversies, I decided I needed to do a careful
reading of this document. While I respect and appreciate what
the authors are trying to do, as a would-be standards track
specification, it is pretty troubling. It is troubling
editorially as well.
I think all or most of the specific
On 2011-06-15 17:59, Boris Zbarsky wrote:
On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote:
The point of this comment is to propose abandoning normalization of
'about' URIs because of some ad hoc behavior of an only application -
Gecko.
No, it's to propose abandoning normalization because it's
On 2011-06-16 10:59, Lachlan Hunt wrote:
On 2011-06-15 17:59, Boris Zbarsky wrote:
On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote:
The point of this comment is to propose abandoning normalization of
'about' URIs because of some ad hoc behavior of an only application -
Gecko.
No, it's to
On 2011-06-16 11:14, Julian Reschke wrote:
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.
Theoretical purity is not a
On 2011-06-16 11:20, Lachlan Hunt wrote:
On 2011-06-16 11:14, Julian Reschke wrote:
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
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
On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote:
Applications SHOULD resolve unrecognized about URIs in the
same way as about:blank.
...
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,
16.06.2011 12:35, Julian Reschke wrote:
On 2011-06-16 11:20, Lachlan Hunt wrote:
On 2011-06-16 11:14, Julian Reschke wrote:
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
15.06.2011 23:16, Andrew Sullivan wrote:
On Wed, Jun 15, 2011 at 06:05:33PM +0300, Mykyta Yevstifeyev wrote:
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
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,
16.06.2011 11:59, Lachlan Hunt wrote:
On 2011-06-15 17:59, Boris Zbarsky wrote:
On 6/15/11 5:07 AM, Mykyta Yevstifeyev wrote:
The point of this comment is to propose abandoning normalization of
'about' URIs because of some ad hoc behavior of an only application -
Gecko.
No, it's to propose
Subject: Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The
'about' URI scheme) to Proposed Standard
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
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.
On 2011-06-15 11:07, Mykyta Yevstifeyev wrote:
...
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
15.06.2011 13:13, Julian Reschke wrote:
On 2011-06-15 11:07, Mykyta Yevstifeyev wrote:
...
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
On Wed, Jun 15, 2011 at 06:05:33PM +0300, Mykyta Yevstifeyev wrote:
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
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
On Sat, Jan 22, 2011 at 1:47 AM, Julian Reschke julian.resc...@gmx.de wrote:
I believe about qualifies for permanent as per
http://tools.ietf.org/html/rfc4395#section-2, if there's something
essential missing, we should fix it.
Hi Julian,
I think the key question is whether this qualifies as
Hi Ted,
At 10:02 24-01-11, Ted Hardie wrote:
I think the key question is whether this qualifies as well-defined
(section 2.3).
The draft declares some tokens/strings to be reserved, and names one such
string. It also declares that other strings may be reserved by other
specifications,
but it
Hi Ted,
On 21.01.2011 23:49, Ted Hardie wrote:
This rationale isn't in the draft, nor is the token legacy-compat.
...because HTML5 defines it... (I think)
But the question with this how you will get interoperability. If there is a
token registry, then these should populate that registry
On 21.01.2011 18:37, Julian Reschke wrote:
...
That said, I note that HTML5 has a number of what it calls willful
violations
of the URI spec, in which it counsels the reading who actually knows what
Sadly.
...
BTW: http://www.w3.org/html/wg/tracker/issues/56. We should try to
improve this,
On 21.01.2011 02:13, Ted Hardie wrote:
...
But the reality is that the behavior resulting from these URIs is totally
non-deterministic and varies from context to context. In most contexts
outside of a browser location bar, they are meaningless. Inside that
context, the browser's definition
Howdy,
Some comments in-line.
On Fri, Jan 21, 2011 at 12:28 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 21.01.2011 02:13, Ted Hardie wrote:
...
But the reality is that the behavior resulting from these URIs is totally
non-deterministic and varies from context to context. In most
On 21.01.2011 17:57, Ted Hardie wrote:
Howdy,
...
Reminder: the reason this was written down was so that about:legacy-compat
can be specified as XML system identifier in HTML5
(http://dev.w3.org/html5/spec/Overview.html#the-doctype).
This rationale isn't in the draft, nor is the token
Howdy,
Some further replies in-line.
On Fri, Jan 21, 2011 at 9:37 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 21.01.2011 17:57, Ted Hardie wrote:
Howdy,
...
Reminder: the reason this was written down was so that
about:legacy-compat
can be specified as XML system identifier in
At 07:56 14-01-11, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'The 'about' URI scheme'
draft-holsten-about-uri-scheme-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
I agree with SM's concern that the mechanism by which this is
extended is underspecified. The draft contains one reserved
token, blank, and a set of examples which make clear that there
is an unwritten set of known and unknown tokens which populate the segment
portion of the given ABNF.
2011/1/21, Ted Hardie ted.i...@gmail.com:
I agree with SM's concern that the mechanism by which this is
extended is underspecified. The draft contains one reserved
token, blank, and a set of examples which make clear that there
is an unwritten set of known and unknown tokens which populate
41 matches
Mail list logo
