Larry Masinter
2012-07-30 18:05:45 UTC
IRIs are widely deployed and referenced;
RFC 3987 is referenced by 42 RFCs
http://www.arkko.com/tools/allstats/citations-rfc3987.html
and many W3C specs:
https://www.google.com/search?q=3987+rfc+site%3Awww.w3.org%2FTR
at least some of which use IRIs or something like them as protocol elements.
The problem is that we have at least 3 different classes
RFC 3987-compatible < LEIRI compatible (used in XML) < browser-compatible (used in HTML and other browser implementations).
HTML5 allows use of document character set for query parameters, and a wide variety of characters not valid in LEIRI, but of course allows RFC 3987 compatible.
LEIRI allows RFC 3987 but also spaces.
The question is whether any of the protocols that allow IRIs really need to maintain RFC 3987 compatibility, or would want to be compatible with browsers.
I think "web applications" (i.e., things built with the HTML javascript-engine) want to be compatible with browsers.
RFC 3987 is referenced by 42 RFCs
http://www.arkko.com/tools/allstats/citations-rfc3987.html
and many W3C specs:
https://www.google.com/search?q=3987+rfc+site%3Awww.w3.org%2FTR
at least some of which use IRIs or something like them as protocol elements.
The problem is that we have at least 3 different classes
RFC 3987-compatible < LEIRI compatible (used in XML) < browser-compatible (used in HTML and other browser implementations).
HTML5 allows use of document character set for query parameters, and a wide variety of characters not valid in LEIRI, but of course allows RFC 3987 compatible.
LEIRI allows RFC 3987 but also spaces.
The question is whether any of the protocols that allow IRIs really need to maintain RFC 3987 compatibility, or would want to be compatible with browsers.
I think "web applications" (i.e., things built with the HTML javascript-engine) want to be compatible with browsers.