- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 17 Sep 2009 10:51:27 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Ian Hickson <ian@hixie.ch>, URI <uri@w3.org>, hybi@ietf.org, uri-review@ietf.org, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
On Sep 17, 2009, at 3:34 AM, Julian Reschke wrote: > Ian Hickson wrote: >> ... >>> I meant Section 3.1, which essentially is useless, as it >>> replicates what's said in the ABNF in the registration template. >> The ABNF doesn't say how you parse the URI, it says how you check >> if it's valid. Section 3.1 doesn't say how you parse the URI, it >> says how you > > Actually, unless it's ambiguous, an ABNF *does* define how to parse. Actually, no, the purpose of an ABNF is to define the grammar for generating valid strings and testing strings for validity. It might be used as a guide by something like lex to create a parser that enforces validity while parsing, but that generally is not done in Internet-facing software because of Postel's Law. For example, RFC 3986 has a very specific grammar for generation and validity of URIs, but also describes one parsing algorithm (not the only one, but certainly one in common use) in an Appendix that will accept any string and parse it into the major components. And I'll reiterate, again, that the algorithm for reference parsing in HTML5 is not definitive of URLs -- it is just a variation on the appendix in RFC3986 that includes a non-ASCII character encoding step. The entire notion that this has anything to do with IRI or URI definition, or that we need to fix any of the IETF specs to incorporate browser-specific reference error-handling, is simply absurd. They are not the same thing. ....Roy
Received on Thursday, 17 September 2009 17:53:33 UTC