[whatwg] Web Addresses vs Legacy Extended IRI
julian.reschke at gmx.de
Mon Mar 23 11:28:23 PDT 2009
Ian Hickson wrote:
> On Mon, 23 Mar 2009, Julian Reschke wrote:
>> You are essentially proposing to change existing specifications (such as
>> Atom). I just do not see the point.
> The point is to ensure there is only one way to handle strings that are
> purported to be IRIs but that are invalid. Right now, there are at least
> three different ways to do it: the way that the URI/IRI specs say, the way
> that the LEIRI docs say, and the way that legacy HTML content relies on.
> My understanding is that even command line software, feed readers, and
> other non-Web browser tools agree that the specs are wrong here.
> For example, curl will not refuse to fetch the URL http://example.com/%
> despite that URL being invalid.
Should it refuse to?
> Thus, we need a spec they are willing to follow. The idea of not limiting
> it to HTML is to prevent tools that deal both with HTML and with other
> languages (like Atom, CSS, DOM APIs, etc) from having to have two
> different implementations if they want to be conforming.
I understand that you want everybody to use the same rules, and you want
these rules to be the ones needed for HTML content. I disagree with that.
Do not leak that stuff into places where it's not needed.
For instance, there are lots of cases where the Atom feed format can be
used in absence of HTML.
> If you think it's worthwhile, propose that change to the relevant
>> standards body (in this case IETF Applications Area).
> This was the first thing we tried, but the people on the URI lists were
> not interested in making their specs useful for the real world. We are now
> routing around that negative energy. We're having a meeting later this
> week to see if the IETF will adopt the spec anyway, though.
Adopting the spec is not the same thing as mandating its use all over
More information about the whatwg