W3C home > Mailing lists > Public > www-archive@w3.org > October 2002

Re: draft-kindberg-tag-uri

From: Dan Connolly <connolly@w3.org>
Date: 30 Oct 2002 07:38:29 -0600
To: Patrik Fältström <paf@cisco.com>
Cc: www-archive@w3.org, Ned Freed <ned.freed@mrochek.com>, timothy@hpl.hp.com, Sandro Hawke <sandro@w3.org>, Dan Connolly <connolly@w3.org>
Message-Id: <1035985110.25017.9270.camel@dirk>

On Tue, 2002-10-29 at 21:46, Patrik Fältström wrote:
> On tisdag, okt 29, 2002, at 23:47 Europe/Stockholm, Dan Connolly wrote:
> 
> > I certainly don't agree with:
> >
> > "But there are
> >    drawbacks to URLs-as-identifiers:
> >
> >    1) Software might try to dereference a URL-as-identifier, even 
> > though
> >       there is no resource at the "location"."
> >
> > (a) there's always a resource there; there might not be a 
> > representation
> > available. But (b) if there isn't a representation available, there
> > should be.
> 
> When using a URI, there might not always be a resource there as the URI 
> itself can exist just because a unique identifier is needed. Whether 
> that unique identifier is said to represent something, yes,

And that something is the resource in question.

> whether 
> dereferencing it is actually giving back some bytes when you use the 
> protocol specified in the URI scheme is a different story.

Quite; as I said "there might not be a representation available."

> Here is where the IETF and W3C view is different,

These are complex organizations; inasmuch as they have views,
their views are matters of record. So unless you can
cite a source for this difference, I don't see what you
mean by it.

> and I am sure your 
> view is correct _for_specific_URI_schemes_, it is not for all of them.

My view is what it is. You may disagree, but that doesn't make
your view any more "correct" than mine.

If it's not correct for all of them, then there's one for which
it is not correct. Which one?

>      paf
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 30 October 2002 08:39:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:54 UTC