- From: Dan Connolly <connolly@w3.org>
- Date: 30 Jul 2002 08:51:42 -0500
- To: www-tag@w3.org
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