From: firstname.lastname@example.org (Al Gilman) Message-Id: <9511221840.AA19004@severn.wash.inmet.com> Subject: Re: mid and cid URLs To: email@example.com (Larry Masinter) Date: Wed, 22 Nov 1995 13:40:51 -0500 (EST) Cc: firstname.lastname@example.org In-Reply-To: <95Nov22.email@example.com> from "Larry Masinter" at Nov 22, 95 10:19:52 am To follow up on what Larry Masinter said ... I was actually speaking of mid: and cid:, not mailserver: or mailto:, but the argument is similar: Sorry, I answered from the wrong context. mid: refers to messages cid: refers to message bodies and other content Message-ID is changed if you re-send the same content, but Message-ID is still a key which lets you know you have the right content if it matches. This is the way it is used in intermodal operations between News and Mail. I a recommending that both MID and CID as used in Mail and MIME be regarded as most useful as content keys which fit the definition Roy gave for a URN. It allows the client to verify content identity independent of access method or source of retrieval. If you are sometimes going to qualify a part by the Message-ID as well as its Content-ID, you need a syntax with room for both parts. Ed provided this. I still want to emphasize that '?' is more literate URI language than '#' for the punctuation in this form. Let the syntactic scheme be thisURI ::= scheme-name: "message-unique@path-to-host"?content-descriptor ( ; header-phrase ) content-descriptor ::= "content-unique [ @ host-path-if-different ] scheme-name ::= ; one or choice Since both semantic classes fit neatly into this harmonized syntax, you introduce only ONE new scheme and you are done. I really don't understand why I have to keep explaining this on the _Uniform_ resource identification list. mailto: refers to interactive mail mailserver: refers to pre-scripted mail You and the tool don't really know. For security reasons there is no such thing as non-interactive mail. For infobots such as firstname.lastname@example.org, a simple mailto: URL is enough. All the URL processing client program is going to do is send mail. The difference between chatting with a buddy and retrieving an archived object should be handled in the heuristic text contained in the anchor and need not be keyed to the tool by the URI. The tool should handle both cases the same. It must MayI the user for everything in the script. It's the same reason why there are two z39.50 URL schemes being proposed. That may be good or bad. I haven't reviewed that one.