[Uri-review] discussion of 'tag' scheme

["Larry Masinter" <[e-mail]>]

(reply to follow)

-----Original Message-----
From: Tim Kindberg [mailto:[e-mail]] 
Sent: Tuesday, March 18, 2003 10:17 AM
To: Larry Masinter; 'Tim Kindberg'; 'Sandro Hawke'
Cc: 'Patrik Fältström'
Subject: RE: (slightly) request for URI BOF scheduling 


Hi Larry,

At 09:50 PM 2/27/2003 -0800, Larry Masinter wrote:
>RFC 2718 "guidelines for new URL schemes" spells out
>considerations for new schemes. In my personal
>opinion (I have no official standing), the scheme
>defined in draft-kindberg-tag-uri-04.txt doesn't
>fit the guidelines very well.

It would be very helpful if you could tell me where you think tag fails.

Looking  back over RFC 2718, I guess you feel it breaks the first para
of 2.2:

'It is important that the semantics of the "resource" that a URL
"locates" 
be well defined.'

But I find the following place which applies more specifically to tag
and 
where you might have concerns:

2.2.3:
"In some cases, URL schemes do not have particular network protocols 
associated with them, because their use is limited to contexts where the

access method is understood. This is the case, for example, with the
"cid" 
and "mid" URL schemes. For these URL schemes, the specification should 
describe the notation of the scheme and a complete mapping of the
locator 
from its source."

Unfortunately, I don't know what "mapping of the locator from its
source" 
means (name to URL of resource?).

But 2.2.3 caused me to revisit the spec for mid and cid.  As you're
aware, 
those respectively identify a message or an item of content in a
multipart 
message.

The spec demands that such id's be globally unique (it doesn't mandate
how 
that should be achieved) and conform to an RFC 822 'addr-spec' syntax.

The only statement about the semantics of denotation in RFC2392 is:
'A "mid" URL with only a "message-id" refers to an entire message. With
the 
appended "content-id", it refers to a body part within a message, as
does a 
"cid" URL.'

The spec does not define how the "look-up" is achieved -- it's
implicitly 
done by an email system; but note that that system must start from
locating 
the identifiers within the messages and then make the referents
available 
through an index.  That's OK as far as I can see.  It's starting to
remind 
me of something else.... search engines.

I suppose I could devise a "wid:" spec: if a client encounters <a 
href="wid:....">, it does a google (say) look-up on that identifier.

Similarly, I could devise a mp3id:... spec, so that an app that deals in

music clips could look through my stored music -- or look for mp3 files
on 
the Internet (maybe something like this already exists).

But the essential properties in each case are (a) a way of making 
human-tractable globally unique id's and (b) a domain-specific search
strategy.

Wouldn't it be a step forward to standardise on the (a) part?  A spec
for 
"wid" (or whatever) could then just say "wid identifiers use the "tag" 
syntax for uniqueness (so they're of the form 
wid:[e-mail],2003:....) .

Alternatively, a "content-addressible Web" spec -- which I'm going to
write 
-- could just say "put a page-specific tag URI in the HTML TITLE and/or 
META DC:ID element; clients may then find the page via a search engine 
'proxy'" (to use the language of RFC2718).

Stepping back, note that I haven't defined a tag-specific resolution
scheme 
in the above.  Actually, as you've probably heard me say before, I have 
written about web/id as such a thing 
(http://www2002.org/CDROM/refereed/485/index.html) but haven't yet
written 
it into an ID.  It seems to me that it's orthogonal to tag, which is
part 
of the "naming infrastructure" that web/id assumes.

So does this notion of tag URI's as naming infrastructure help?

Cheers,

Tim.


Tim Kindberg
hewlett-packard laboratories
1501 page mill road, ms 1138
palo alto
ca 94304-1126
usa

purl.org/net/TimKindberg/home
[e-mail]
voice [phone]
fax [phone]


_______________________________________________
Uri-review mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/uri-review