Ed Barkmeyer wrote:
> With respect to what is actually supported by W3C and IETF standards, there
> have been a few bits of misinformation bandied about in this discussion. (01)
> Waclaw Kusnierczyk wrote:
>> Re: John Sowa's post on URIs etc.
>>
>> "This discussion raises some serious issues: (01)
>>
>> 4. The URLs and URIs of the WWW are based on a naming
>> scheme that ultimately resolves to physical devices.
>> It guarantees that an identifier will determine a
>> unique storage location at a given point in time. (05)"
>>
>> This is not exactly true. In w3 specs [1] we read:
>>
>> "A Uniform Resource Identifier (URI) is a compact sequence of characters
>> that identifies an abstract or physical resource", and further that "in
>> many cases, URIs are used to denote resources without any intention that
>> they be accessed" and "a common misunderstanding of URIs is that they
>> are only used to refer to accessible resources. The URI itself only
>> provides identification; access to the resource is neither guaranteed
>> nor implied by the presence of a URI."
>>
>> A URL is a URI with a specialized syntax: "A URI can be further
>> classified as a locator, a name, or both. The term "Uniform Resource
>> Locator" (URL) refers to the subset of URIs that, in addition to
>> identifying a resource, provide a means of locating the resource by
>> describing its primary access mechanism". Ultimate resolution to
>> physical devices is *not* a part of the scheme.
>>
>> "
>> 5. However, the policies of the WWW and of each domain
>> on the WWW permit the same identifiers to be resolved
>> to different physical locations at different times. (06)
>> "
>>
>> Precisely. URLs, those that do identify locations, identify them in
>> virtue of there being a mapping from a particular URI to a physical
>> address, by means of dns services. And if there is no such mapping,
>> there is no translation, and in effect the URL does not identify a
>> location -- try, e.g., 'http://www.nonsense.no', a (syntactically)
>> *valid* URL. Some (most?) valid URLs do *not* ultimately resolve to a
>> physical device.
>
> This is technically partly correct, but the paragraph is badly misleading.
>
> What RFC 2396 says is that a URL begins with a prefix that identifies an
> Internet access protocol, and it is required to have the syntax required by
> the specification for that protocol and the interpretation associated with
> that syntax.
>
> The HTTP standard (RFC 2616) defines the rest of the syntax of URIs beginning
> http:, and says:
>
> 3.2.2 HTTP URL
>
> The "http" scheme is used to locate network resources via the HTTP
> protocol. This section defines the scheme-specific syntax and
> semantics for http URLs.
>
> http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
>
> If the port is empty or not given, port 80 is assumed. The semantics
> are that the identified resource is located at the server listening
> for TCP connections on that port of that host, ...
>
> And, by adoption of text from RFC 2396:
> The host is a domain name of a network host, or its IPv4 address ...
>
> That is, the URL *means* that the resource is accessible at the designated
> host via the HTTP TCP port. It doesn't refer to a *physical device*, but it
> does refer to a specific *host*, and indirectly to the physical device that
> currently responds to that TCP/IP address and provides network services.
>
> If the URL doesn't mean that, it is not a "valid" HTTP URL, because it does
> not satisfy the requirements of RFC 2616. So the example URI that Waclaw
>offers:
> 'http://www.nonsense.no'
> is NOT a "valid" URL. It may satisfy the grammar requirements, but it
> probably does not satisfy the syntactic requirement for www.nonsense.no to be
> a valid domain name (i.e., a sequence of characters registered as a domain
> name through the Internet cascading directory scheme). And it surely doesn't
> satisfy the requirement for it to refer to an accessible resource. So it is
> likely to be *syntactically invalid* and it has *no valid interpretation*. (02)
Agreed. I should have written *syntactically valid* instead of
(syntactically) *valid*. And according to the interpretation of 'valid'
that you advocate here, one can make sure that a string is a valid url
only by actually connecting to the host and receiving a response. (03)
vQ (04)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (05)