- From: Al Gilman <asg@severn.wash.inmet.com>
- Date: Tue, 21 Nov 1995 17:55:27 -0500 (EST)
- To: moore@cs.utk.edu (Keith Moore)
- Cc: asg@severn.wash.inmet.com, elevinso@Accurate.COM, ietf-types@cs.utk.edu, uri@bunyip.com, moore@cs.utk.edu
To follow up on what Keith Moore said ... > 1. By construction, these two nominal schemes are one scheme and we > should only use one name for them. MID or MIDCID are possibles. No they're not the same, and as long as we're talking about URLs, we shouldn't try to force the two into a single scheme. Looking at what follows the ( mid | cid ): in Ed's syntax, what is different? They are the same syntax scheme. a) A message is not the same as a body part. A message has senders, recipients, a subject, and so on, in addition to content. A body part just has typing information and content. Message and Part URIs can be told apart anyway, without peeking at the scheme prefix. That is my argument. You don't need to use two scheme-names because you can tell 'em apart anyway. I am not attempting to assume that Content-IDs and Message-IDs are jointly World-unique, although I bet they are. All a URI is is a key. The syntax for the key can be the same and the semantic class of the two subsets of keyed objects still be different. That's all MIME processing is allowed to know it has. URIs don't have to be so blind. There could be other headers on the part. b) The likely use of CID is to reference bodyparts within a multipart/related. The likely use of MID is to refer to messages in a message store (like an IMAP server). Some mail readers will support one and not the other. The two need to be able to succeed or fail on their own merits, rather than trying to load each one with the other's burdens. If that's the only use, you don't need to define a URI to cover the cid case. To define a URI, you need to think of the bulk of the URI users who are not MIME mail handlers. c) You don't want to refer to a body part as a message-id plus an offset. The same body part (with the same CID) can occur in multiple messages. I now understand the risks (Thanks, Ned). At least the message originating agent would know the right part numbering, so a part-number-path URL returned to the sending node would function correctly as a part key. The alternate syntax I suggested still supports object identification by matching the Content-ID markup. Either MIDs or CIDs could probably be implemented fairly easily, and (at least as importantly) consistently between differnet platforms. But for a combined MID/CID, you don't know where to find the object. By either my syntax or Ed's syntax, the two kinds of identifiers are syntactically distinguishable without reference to the scheme-name. Here is an example which assumes that one retrieves by Content-ID without reference to any Message-ID. I'll start with the more URL-traditional syntax. mid: //path-to-host/?part-unique ; is Content-ID mid: //path-to-host/message-unique ; is Message-ID Here is a rough hack at Ed's syntax for these: cid: "#part-unique@path-to-host" ; is Content-ID mid: "message-unique@path-to-host" ; is Message-ID You can throw a blanket over the scheme prefix and still tell these apart. And you know one place to go: There is a path-to-host in either one. Even if a message is sent from one site embedding a part Content-ID-ed at another node, you have two places to go, which may be better than just being told one, because only one may support archiving. It's a Bad Idea to try to impose URN functionality on URLs. In order to implement URNs, we need a URL substrate that works simply and rationally. Wrong. Equally bad to fail to document incumbent URN forms (which Message-ID is) while waiting for the retrieval services to materialize. Message-ID Al
Received on Tuesday, 21 November 1995 17:59:54 UTC