Re: MIME for global hypertext

Dan Connolly (connolly@pixel.convex.com)
Mon, 08 Jun 92 15:50:17 CDT 

Message-Id: <9206082050.AA15921@pixel.convex.com>
To: mitra@pandora.sf.ca.us ()
Cc: wais-talk@think.com, www-talk@nxoc01.cern.ch
Subject: Re: MIME for global hypertext 
In-Reply-To: Your message of "Mon, 08 Jun 92 13:11:15 PDT."
             <9206081311.aa26440@pandora.sf.ca.us> 
Date: Mon, 08 Jun 92 15:50:17 CDT
From: Dan Connolly <connolly@pixel.convex.com>



>My question is on a fairly minor point of your document, you mention that 
>a MIME document typically consists of a content and then the pointers, 
>with the hypertext links being references to the pointers.

Well, this is not typical, but it's the model I'm proposing for
hypertext. Typically MIME message bodies are either single part
text/image/audio, or multipart. The standard multipart types
are mixed, meaning "show these one after the other," parallel,
meaning "show these at the same time," or alternative, meaning
"these all represnt the same info. Take your pick."

The "content and then list of pointers [or attachments]" model
is my own proposed format for hypertext.

>  In Wais, it 
>is quite possible to return part of a document (by byte position), and 
>if the pointers are part of the document itself then they may not be 
>returned at the time the user chooses to try and follow a link? 
>
I would suggest that the WAIS server interpret the byte positions
as offsets into the content part of the hypertext. So the structure
remains in tact. Byte offsets into a MIME multipart message
don't mean much. Transport systems may mess with the headers and
trailing whitespace on body lines. Line offsets may be meaningful
inside text body parts, as long as none of the lines have to be
split due to line length constraints.

Keep in mind that this multipart structure is only necessary for
hypertext (i.e. contains links) and hypermedia (i.e. contains
multimedia attachments) documents.

Traditional documents can be simple single part bodies. For example,
A plain text file starting with a new-line will be interpreted as
a body part with no headers, which defaults to the type
"text/plain; charset=US-ASCII" ,i.e. plain old text.

>My concerns are around doing these things for users on low-speed (2400 baud)
>modems....