Web and Mail integration: a few key connections.

Path: gmd.de!rrz.uni-koeln.de!news.rhrz.uni-bonn.de!urmel.informatik.rwth-aachen.de!
news.dfn.de!zib-berlin.de!math.fu-berlin.de!xlink.net!howland.reston.ans.net!
vixen.cso.uiuc.edu!gateway
From: t...@www3.cern.ch (Tim Berners-Lee)
Newsgroups: info.ietf
Subject: Web and Mail integration: a few key connections.
Date: 4 Nov 93 16:34:27 GMT
Organization: University of Illinois at Urbana
Lines: 141
Approved: Use...@ux1.cso.uiuc.edu
Message-ID: <9311041634.AA05009@www3.cern.ch>
Reply-To: t...@nxoc01.cern.ch
NNTP-Posting-Host: ux1.cso.uiuc.edu
Originator: dae...@ux1.cso.uiuc.edu


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.

 	Background
 	==========
	
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,
no URNs.

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.

	Proposals
	=========
	
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
    

    	fpi:
	cid:
	mid:

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
     		Accept: multipart/related
     header in the HTTP request.


I think that's everything.


	References for working documents and discussion lists:
	==========
	
URI, URL:
 ftp://ftp.internic.net/internet-drafts/draft-ietf-uri-url-01.ps
 mailto:uri-requ...@bunyip.com

HTML:
 ftp://ftp.internic.net/internet-drafts/draft-ietf-iiir-html-01.ps
 mailto:www-talk-requ...@info.cern.ch

HTTP:
  ftp://info.cern.ch/pub/www/doc/http-spec.ps
  mailto:www-talk-requ...@info.cern.ch

SGML-MIME:
  ftp://ftp.internic.net/internet-drafts/draft-ietf-mime-sgml-00.txt 

  mailto: ietf-822-requ...@dimacs.rutgers.edu

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!

Tim Berners-Lee
CERN