- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 27 Sep 2009 08:51:00 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>, Larry Masinter <masinter@adobe.com>, "PUBLIC-IRI@W3.ORG" <PUBLIC-IRI@w3.org>
Maciej Stachowiak wrote: > ... > I don't see a great advantage in splitting the specs, as this makes > cross-references more complicated. If it were just a matter of > transforming the kind of string that may appear in an "href" attribute > into a valid IRI, then your proposal might be plausible. However, in > addition to converting to a URI, HTML UAs also need to be able to do the > following to resource identifiers treated with lenient processing: (a) > separate into components, even when the string is not a valid URI or > IRI, and in a way that is not necessarily equivalent to first converting > to a valid IRI or URI; (b) resolve a reference relative to a base when > either the reference or the base might not be a valid URI or IRI; (c) > determine if a reference is "absolute" even if it might not be a valid > URI or IRI. That would mean a great deal of algorithms defined in a > totally separate place from the URI spec. This is what the Web Address > spec[1] attempted to do, and it ends up duplicating a lot of concepts > from IRI/URI. This effort was set aside in favor of IRIbis incorporating > the necessary content. > ... a) As already mentioned in this thread, it appears this is covered by the text in <http://tools.ietf.org/html/rfc3986#appendix-B>. b) Could you remind us why it's not possible to translate both to valid URI/IRI and references first and then use the standard behavior? c) Again, see <http://tools.ietf.org/html/rfc3986#appendix-B>. I do realize that a more normative way of what Appendix B says may be needed, but please let's not dismiss what's already in the spec as unusable. BR, Julian
Received on Sunday, 27 September 2009 06:51:42 UTC