W3C home > Mailing lists > Public > uri@w3.org > June 2008

Re: Error handling in URIs

From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Wed, 25 Jun 2008 03:22:58 +0200
To: uri@w3.org
Message-ID: <g3s6i9$g3a$1@ger.gmane.org>

Ian Hickson wrote:

Hi, I tackled your first example in another article.

Yes, I think you can take the core of RFC 3987 as stable,
and STD 66 as rock solid for at least a decades until a
wannabe-improvement not yet existing as Internet draft
could make it to STD.  

Unfortunately even RFC 2616 might turn out to be more
"stable" than anybody would wish, but that doesn't mean
you should overrule it in HTML5.  The HTTPbis WG has a
fundamental problem of having no strategy to get from
"default Latin-1" to UTF-8 in a consistent way (or in
a reasonable timeframe not involving decades). 

> Similarly, what should the script in the following
> example display in the alert dialog box, assuming a
> base URL of http://example.com/ ?
>    <title>Test</title>
>    <p><a href="{{%%xx##">Test</a>
>    <script>alert(document.links[0].href)</script>
> Where is this defined?

The odd DOCTYPE is defined by you, so you're supposed
to know what it means.  I'd say for similar document
types the href= attribute value is no form of STD 66
URI I can identify at first glance.  Especially curly
braces are nowhere permitted in any STD 66 URI, they
are no <pchar>.  It took me a year to get this for a
news URI spec., the STD 66 authors did not bother to
list the about ten "impossible" VCHARs.

So that is no URI, and better don't ask the poor IANA
example.com server for a second opinion.  It is also
no IRI, and percent-encoding the curly braces doesn't
help - unless you think it is a cute way to deal with
this error condition.  But a specification going too
far into implementation details is a matter of taste:
I'd love it when I agree, and hate it otherwise.

Received on Wednesday, 25 June 2008 01:22:03 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:51 UTC