As per Relevance of the word copyright, we have this rfc below:
Network Working Group E.
Request for Comments: 2392 August 1998
Obsoletes: 2111
Category: Standards
Content-ID and Message-ID Uniform Resource
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
The Uniform Resource Locator (URL) schemes, "cid:" and "mid:"
references to messages and the body parts of messages. For example
within a single multipart message, one HTML body part might
embedded references to other parts of the same message
Changes from (RFC 2111)
Clarified the example on page 3 on of converting cid URLs
Content-IDs. The example now uses a cid URL instead of an mid
Corrected the example messages to have the correct Content-ID form
they now use the angle brackets. Added a Message-ID header to
second example
1.
The use of [MIME] within email to convey Web pages and
associated images requires a URL scheme to permit the HTML to
to the images or other data included in the message. The Content-
Uniform Resource Locator, "cid:", serves that purpose
Similarly Net News readers use Message-IDs to link related
together. The Message-ID URL provides a scheme, "mid:", to refer
such messages as a "resource".
Levinson Standards Track [Page 1]
RFC 2392 Message- & Content-ID URLs August 1998
The "mid" (Message-ID) and "cid" (Content-ID) URL schemes
identifiers for messages and their body parts. The "mid" scheme
(a part of) the message-id of an email message to refer to a
message. The "cid" scheme refers to a specific body part of
message; its use is generally limited to references to other
parts in the same message as the referring body part. The "mid
scheme may also refer to a specific body part within a
message, by including the content-ID's address
A note on terminology. The terms "body part" and "MIME entity"
used interchangeably. They refer to the headers and body of a
message, either the message itself or one of the body parts
in a Multipart message
2. The MID and CID URL
RFC 1738 [URL] reserves the "mid" and "cid" schemes for Message-
and Content-ID respectively. This memorandum defines the syntax
those URLs. Because they use the same syntactic elements they
presented together
The URLs take the
content-id = url-addr-
message-id = url-addr-
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-
cid-url = "cid" ":" content-
mid-url = "mid" ":" message-id [ "/" content-id ]
Notes: In Internet mail messages, the addr-spec in a Content-
[MIME] or Message-ID [822] header is enclosed in angle
(<>). Since addr-spec in a Message-ID or Content-ID might
characters not allowed within a URL; any such character (
"/", which is reserved within the "mid" scheme) must be hex-
using the %hh escape mechanism in [URL].
A "mid" URL with only a "message-id" refers to an entire message
With the appended "content-id", it refers to a body part within
message, as does a "cid" URL. The Content-ID of a MIME body part
required to be globally unique. However, in many systems that
messages, body parts are not indexed independently their
(message). The "mid" URL long form was designed to supply
context needed to support interoperability with such systems
Levinson Standards Track [Page 2]
RFC 2392 Message- & Content-ID URLs August 1998
A implementation conforming to this specification is required
support the "mid" URL long form (message-id/content-id).
implementations can choose to, but are not required to,
advantage of the content-id's uniqueness and interpret a "cid" URL
refer to any body part within the message store
In limited circumstances (e.g., within multipart/alternate), a
message may contain several body parts that have the same Content-ID
That occurs, for example, when identical data can be accessed
different methods. In those cases, conforming implementations
required to use the rules of the containing MIME entity (e.g.,
multipart/alternate) to select the body part to which the Content-
refers
A "cid" URL is converted to the corresponding Content-ID
header [MIME] by removing the "cid:" prefix, converting the %
character to their equivalent US-ASCII characters, and enclosing
remaining parts with an angle bracket pair, "<" and ">".
example, "cid:foo4%25foo1@bar.net" corresponds
Content-ID:
Reversing the process and converting URL special characters to
% encodings produces the original cid
A "mid" URL is converted to a Message-ID or Message-ID/Content-
pair in a similar fashion
Both message-id and content-id are required to be globally unique
That is, no two different messages will ever have the same Message-
addr-spec; no different body parts will ever have the same Content-
addr-spec. A common technique used by many message systems is to
a time and date stamp along with the local host's domain name, e.g.,
950124.162336@XIson.com
Some
The following message contains an HTML body part that refers to
image contained in another body part. Both body parts are
in a Multipart/Related MIME entity. The HTML IMG tag contains
cidurl which points to the image
From: foo1@bar.
To: foo2@bar.
Subject: A simple
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1";
type=Text/
Levinson Standards Track [Page 3]
RFC 2392 Message- & Content-ID URLs August 1998
--boundary-example 1
Content-Type: Text/HTML; charset=US-
to the other body part, for example through a statement such as
--boundary-example-1
Content-ID:
Content-Type: IMAGE/
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4
etc...
--boundary-example-1--
The following message points to another message (hopefully still
the recipient's message store).
From: bar@none.
To: phooey@all.
Subject: Here's how to do
Message-ID: <970701.32784@VIers.none.com
Content-type: text/html; charset=
previous message, shows how the approach you propose can
used to accomplish ...
3. Security
The URLs defined here provide an addressing or referencing mechanism
The values of these URLs disclose no more about the
environment than the corresponding Message-ID and Content-ID values
Where concern exists about such disclosures the originator of
message using mid and cid URLs must take precautions to insure
confidential information is not disclosed. Those precautions
already be in place to handle existing mail use of the Message-ID
Content-ID
Levinson Standards Track [Page 4]
RFC 2392 Message- & Content-ID URLs August 1998
4.
[822] Crocker, D., "Standard for the Format of ARPA Internet
Messages", August 1982, STD 11, RFC 822, August 1982.
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet
Bodies", RFC 2045, November 1996.
[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "
Resource Locators (URL)", RFC 1738, December 1994.
[MULREL] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, August 1998.
5.
The original concept of "mid" and "cid" URLs were part of the
Berners-Lee's original vision of the World Wide Web. The ideas
design have benefited greatly by discussions with Harald Alvestrand
Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and
in the MHTML working group
6. Author's
Edward
47 Clive
Metuchen, NJ 08840-1060
Phone: +1 908 549 3716
EMail: XIson@cnj.digex.
Levinson Standards Track [Page 5]
RFC 2392 Message- & Content-ID URLs August 1998
7. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Levinson Standards Track [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
