- From: <Harald.T.Alvestrand@uninett.no>
- Date: Sun, 23 Jul 1995 22:08:52 +0200
- To: drums@cs.utk.edu, ietf-822@dimacs.rutgers.edu, uri@bunyip.com
- Message-Id: <199507232008.WAA00170@dale.uninett.no>
I talked to some people briefly about this during IETF.
Since it points out some problems with "what does an ID identify"
in both MIME and RFC 822, I think "drums" may be a nice "home list"
to discuss it on; I've set reply-to accordingly.
I don't know whether it is either best or appropriate for me to
continue editing this; does anyone feel like taking responsibility?
(Ed Levinson had a previous document on CID URLs, but I've lost my
copy of it, and he seems to have shelved the idea for the moment)
Comments?
Harald A
draft MID and CID URLs July 95
Message-ID and Content-ID URLs
Sun Jul 23 19:16:56 MET DST 1995
Harald Tveit Alvestrand
UNINETT
Harald.T.Alvestrand@uninett.no
Status of this Memo
This document specifies two classes of URsomethings, MID and CID.
The intention is to allow reference to messages and message
components using a syntax that looks much like that used for URLs
in the Web.
This draft document is being circulated for comment. Please send
comments to the author, or to.....
The following text is required by the Internet-draft rules:
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
The file name of this version is draft-alvestrand-not-submitted-
at-all.txt
Alvestrand Expires Jan 96 [Page 1]
draft MID and CID URLs July 95
1. Introduction
When writing information resources, it would sometimes be nice to
have a reasonably unique way of referring to mail and news
messages.
In some cases, like when you are sending a message coded in HTML,
it is also nice to be able to refer to parts of a message by
content-id.
These references are not Uniform Resource Locators, since they do
not encode the location of their objects, neither are they Uniform
Resource Names, since they do not fulfil all requirements of RFC
1737; for lack of a better idea, I call them Reasonably Unique
Identifying Names; this term obviously does not have a four-letter
abbreviation.
2. The Message-ID UR?
2.1. Syntax The syntax of the message-ID locator is
mid = "mid:" message-id
where message-id is imported from STD 12, "Internet Mail", RFC
822. When it is used in protocols which do not allow the full
character set of RFC 822, it must be encoded using the
%-convention.
2.2. The identified object
The message-ID locator resolves to an Internet message.
This identifies a message header and a message body conformant to
RFC 822 and (possibly) MIME; due to the history of Internet
messages, the following differences must be expected between
different copies of the same message:
(1) Variable number of "Received:" lines in the header
(2) Randomized order of other header lines
Alvestrand Expires Jan 96 [Page 2]
draft MID and CID URLs July 95
(3) Addition of "Resent-*" headers
(4) Addition/subtraction of other non-standard headers like "X-
Listproc-version", "Old-Received" or "PP-Warning"
(5) Changes of content-transfer-encoding for MIME messages
(6) Changes of wrapping for multiline headers
An object is still considered the same object after undergoing
these changes.
The following changes may arise because of errors or misfeatures
that are known to occur in Internet mailers, but represent
erroneous representations of the message:
(1) Changes to, addition of or removal of standard headers like
"To:", "Subject:" or "Content-type:"
(2) Substituting tabs for spaces or vice versa
(3) Adding or deleting blank lines at the end of the message
(4) Breaking of lines without using a MIME content-transfer-
encoding
2.3. Resolution
No specific resolution mechanism is defined by this document.
Possible resolution mechanisms include:
(1) Searching through a database of MIDs for messages seen at
this UA
(2) Searching publicly accessible message archives for messages
with this MID
(3) Sending mail to the author of the referencing document to
ask which message he intended to point to
Alvestrand Expires Jan 96 [Page 3]
draft MID and CID URLs July 95
3. The Content-ID UR?
3.1. Syntax
cidref = "cid:" content-id
where content-ID is imported from RFC 1541 (MIME). Percent
encoding must be used when the cid is used in a protocol that does
not allow the full set of CID characters.
3.2. The identified object
The CID references a MIME entity, consisting of headers and body.
The following changes can be applied to a CID-referenced object
without considering the object to be different:
(1) Change of content-transfer-encoding, including recoding of
quoted-printable
(2) Addition or deletion of headers that do not begin with
"content-"; this is necessary to allow the existence of two
messages with the same content-id, but with different
message headers (These should naturally have different
message-ids)
3.3. Resolution
The same resolution mechanisms as for message-ids can be applied
to cids.
4. Security considerations
Security issues are not consiered in this memo.
5. REFERENCES
Alvestrand Expires Jan 96 [Page 4]
draft MID and CID URLs July 95
[DUMMY REFERENCE]
Here is the title of the reference
Alvestrand Expires Jan 96 [Page 5]
Received on Monday, 24 July 1995 03:19:49 UTC