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....