- From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Date: Mon, 19 Jun 2000 17:23:10 -0700
- To: <abrahams@acm.org>
- Cc: <XML-uri@w3.org>, "Andrew Layman" <andrewl@microsoft.com>, "David Turner" <dturner@microsoft.com>
Thanks Paul, Here is something we can work on. James Clark pointed out the same problem [1]. > I continue to have a big problem with this: it takes text that defines when > URI references are considered identical and replaces it by text that does not > define when URI references are considered identical, and indeed does not use > the word "identical" at all. Whatever flexibility in the definition might > be useful, the failure to define terms would make this a disaster for anyone > trying to use the spec without having participated in the discussions that > led to it. As stated in [2] the current equivalence rules are for historic reasons written in the HTTP spec [3] as HTTP caches were among the first to have this problem. Fundamentally, comparison is done on a per octet-by-octet basis with the constraint that relative URIs have to be taken into account when doing so. RFC 2396 currently addresses the two other ways to compare URIs which involves knowing more about the URI spaces used: * The URI spec defines a set of common syntax equivalence rules for the hostname and the default port number etc. but I wouldn't bet that applications get those consistently right at this level. * A URI scheme may define further normalization rules that can have an impact on how URIs are defined. However, as you can never expect that a URI parser knows about the specific scheme you use, there is no guarantee that those normalization rules are followed. However, it is perfectly valid to use the first mechanism only when comparing NS identifiers. What we cannot say is that http://WWW.MICROSOFT.ORG has different semantics than http://www.microsoft.com but this is up to the *generate* of the name to make sure that this doesn't happen. It doesn't matter that they don't match or that the NS parser (the consumer) doesn't find out that they are in fact the same - the only thing that cannot happen is that the generator of the names say that http://WWW.MICROSOFT.COM identifiers one language and http://www.microsoft.com another. The reason why it wasn't a direct part of the initial proposal was that it was hoped that this should be described as part of the URI spec and not necessarily as part of the NS spec but if we can produce wording that clarifies this then I am all for it. Henrik [1] http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0619.html [2] http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0679.html [3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.3
Received on Monday, 19 June 2000 20:23:50 UTC