[httpRange-14] range of mid:, tel:, uuid: etc.

Something I have been noodling on... I hope you
don't mind if I send this before it's completely
thought thru...

Suppose I want to refer to an iCalendar component
via a URI. iCalendar components have uids,

  BEGIN:VEVENT
  UID:20020108T173559Z-12733-69-1-33@dirk.dm93.org
  ...

which are allocated the same way email and
news message IDs are allocated: foo@mydomain,
where mydomain is allocated in the usual way
and foo is allocated any way mydomain chooses,
as long as it never collides.

Do I need a new
	ical:foo@mydomain
URI scheme?

Or can I just use
	mid:foo@mydomain
?

The mid: RFC says:

[[
The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide
identifiers for messages and their body parts.
]]
	-- http://ftp.ics.uci.edu/pub/ietf/uri/rfc2111.txt

and I don't think an iCalendar component is a message.

But I think constraining the range of mid: that way
is a mistake.

I think that the mid: URI scheme should be about the
naming policy that says
	if you own a domain, you can allocate URIs ala
	mid:foo@mydomain, and you can use them for
	whatever you like.

Following this thru would mean we shouldn't have
had a separate news: URI scheme for pointing
to news articles. This makes it kinda hard to tell whether
to try NNTP or IMAP first when you get
a mid: pointer, but I don't think that's
insurmountable.

(The part of the news: URI scheme that refers to
newsgroup names is fine; that's a novel globally-deployed
naming algorithm, backed by a voting process and such.)

This same question came up in discussions of the HTML
object tag... COM folks wanted a new clsid: URI
scheme... I tried to convince them that a generic
uuid: scheme was sufficient, but they seemed to think
they needed something that told them what sort of
thing the UUID was pointing to.

It came up in the tel: URI scheme design too:
do we need different schemes for tel:, fax:, and
modem:? Or just one for e164 numbers?

[[[
2.7.1 Why distinguish between call types?

   URLs locate resources, which in this case is some telecommunications
   equipment at a given phone number. However, it is not necessarily
   enough to know the subscriber number in order to successfully
   communicate with that equipment. Digital phone networks distinguish
   between voice, fax and data calls (and possibly other types of calls,
   not discussed in this specification). To be able to successfully
   connect to, say, a fax machine, the caller may have to specify that a
   fax call is being made. Otherwise the call might be routed to the
   voice number of the subscriber. In this sense, the call type is an
   integral part of the 'location' of the target resource.
   The reason to have the call type in the scheme specifier is to make
   the URL simple to remember and use. Making it a parameter, much like
   the way modem parameters are handled now, will substantially reduce
   the human readability of this URL.
]]]
	-- http://www.ietf.org/rfc/rfc2806.txt

That seems unfortunate/wrong, to me; I'd like to think that
the information about whether you're making a fax or voice
call would be external to the URI name; I'd like to see
just one URI scheme for each global naming scheme.

Somehow, doing a different URI scheme for tel/fax/modem
feels like having different HTML tags for JPEG, PNG,
and GIF images.




-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you in Montreal in August at Extreme Markup 2002?

Received on Tuesday, 30 July 2002 09:51:16 UTC