From: t...@www3.cern.ch (Tim Berners-Lee)
Subject: Web and Mail integration: a few key connections.
Date: 4 Nov 93 16:34:27 GMT
Organization: University of Illinois at Urbana
There are currently two worlds in the IETF which ought to collide:
the multimedia information access world, epitomized by the WWW
architecture, and the RFC822+MIME world of mail. Sorry about the
hastily scribbled nature of this note about tying it all together.
I send it to the entire IETF list because there has been
criticism in the past that ideas have not been aired widely enough.
The Web is the world of information accessible instantly on request.
WWW uses Uniform Resource Identifiers (URIs, see URL ID) to unify
many protocols, but it
also has its own protocol (HHTP, ID coming out) which
has features needed for a clean and complete system.
URIs are sometimes divided into URLs (Locators) which
refer to the use of a particular protocol for aceess,
and URNs (names) which don't. Lots of URLs are defined,
RFC822 is basic Internet mail, and MIME describes how
multimedia can be represented for mail.
HTTP is a request/response stateless internet-style
protocol, which transmits objects around as MIME
messages (except allowing binary transport).
HTTP has a bunch of headers for metainformation
in addition to the MIME ones. These are "URC" information
in terminology of the URI working group.
WWW defines one (soon two) SGML document types
for sending around basic hypertext (+graphics).
The first, "HTML", explicitly uses URIs of other
objects in hypertext links. (See HTML ID)
There has been some discussion recently about how to
send SGML documents along with DTDs and oetr things
which they reference in MIME messages. (see SGML-MIME ID).
SGML documents refer to external entities
as either "PUBLIC", in which case a special "Formal
Public Identifier" (FPI) space is used and everyone
is supposed o know what's in it, or "SYSTEM" in which
case the significance is purely local.
My suggestions for tying this all togther are:
1. In an Internet context, the SGML "SYSTEM" identifiers
should be conventionally URIs. As there are URIs
which refer to a local file system, this does not
rule out refering to local files too.
2. The FPI space should be registered as a URN.
3. Some space inside FPI space should be found for
the URN tree as well.
4. For the case of mail transport, both message-id values
(identifeirs of mail messages) and content-ids
(identifiers of parts of a multpart MIME message)
should be registered as URNs. They will of course
only be dereferencable by people who have been
sent the relevant mail, but that is fine.
Now we have URI schemes
5. The convention is adopted that when a multipart/related
document is sent, that the first part is consuleted for
information about the relationships.
HTML allows links to be made and also allows
the relationships to be given between parts.
6. The metainformation headers in HTTP should be
adopted as the URC format for the URI working group,
with suitable discussion and additions.
This will allow, using the Link: header which
is isomorphous to the HTML element,
relationships to be defined between non-HTML
pars of a MIME multipart/related document.
7. HTTP should be specified to include support
for MIME multipart/related, to solve the problem
of servers which like to send a document with all
its included graphics in one respone.
Acceptance of multipart/related could be made
mandatory or subject to the
header in the HTTP request.
I think that's everything.
References for working documents and discussion lists:
All .ps postscript files have plainascii .txt equivalents.
All documents may be retrieved by URL by sending a message
with a line "send " followed by the URL to r...@info.cern.ch
Please send comments to specific lists only where you can!
SCO's Case Against IBM
November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and
Linux user, talks about the benefits of code availability and the merits
of the SCO vs IBM lawsuit. See SCO vs IBM.
Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review