WAIS APIs

[Dan Connolly]

There are several issues that WAIS and MIME both face. For some
issues, the systems have different requirements, so different
solutions make sense. But for the issue of typing document
content, I feel stronly that WAIS should adopt MIME semantics.

WAIS defines a :type field in the :document structure. Right
now, it's a string with loosely defined semantics. It's a
simple matter to obsolete the :type field with a :content-type
field with MIME semantics as follows:

obsolete MIME compliant
:type "TEXT" :content-type "text"
:type "GIF" :content-type "image/gif"
:type "TIFF" :content-type "image/x-tiff"
:type "PS" :content-type "application/postscript"
:type "WSRC" :content-type "application/x-wais-source"
:type "MIME" :content-type "message"

I believe data served up by existing WAIS servers fits the MIME
content typing system as is. A WAIS client already implements the
semantics of the text, image, audio, video, and application types:
Either you present it, hand it off to something that can,
or punt to a file.

There are other semantics defined by MIME that would be nice
in WAIS clients. But these require that you handle pretty much
the whole MIME syntax. It's not clear that WAIS should adopt
the MIME solutions in these cases.

[I would like to see the world-wide web adopt MIME solutions
for these issues, though.]

In <920608195...@cmns.think.com.Think.COM>, Mr. Spero suggests
that WAIS might be expanded to offer data in a number of types. The MIME
solution to this problem is the "multipart/alternative" body type.

Someone else suggested that the WAIS server might return only
a pointer to the data, and the client could retrieve the actual
content. MIME defines a "message/external-body" type for this.

And I suggested that the server might return a complex document
with text, graphics, and pointers to other data. (World Wide
Web servers return text with pointers, and they're trying to
deal with graphics). I suggested a new "multipart/hypertext"
type to handle this.

Resolving these issues is going to take a lot more thought.
Let's keep interoperability in mind while we do it.

Dan

[Harry Morris]

Date: Tue, 09 Jun 92 18:10:29 CDT
From: Dan Connolly <conn...@pixel.convex.com>

obsolete MIME compliant
:type "TEXT" :content-type "text"
:type "GIF" :content-type "image/gif"
:type "TIFF" :content-type "image/x-tiff"
:type "PS" :content-type "application/postscript"
:type "WSRC" :content-type "application/x-wais-source"
:type "MIME" :content-type "message"

excuse the novice question, but doesn't x-tiff and x-wais-source imply that
a particular program (running on an X Windows display) is to be called?

how do you support other platforms?

[Paul Burchard]

> excuse the novice question, but doesn't x-tiff and x-wais-source

> imply that a particular program (running on an X Windows display)

> is to be called?

If I'm not mistaken the "x-" refers to "experimental". I.e,. these
are not an officially registered MIME types. (There is no X Windows
program called x-tiff, by the way.)

Since these naming schemes serve the same purpose there is no reason
not to have them interoperate; this could be fitted nicely into an
OOP API.

PB

[Simon Edward Spero]

Just going back to multi-part alternative...
Consider:

Alternative/MPEG
Alternative/QuickTime

It's not a sensible solution for anything that doesn't need to be self
contained.


Email and netnews delivery is essentially a one way process, so the documents
need to stand or fall on there own. MIME is the right standard for those
tasks. MIME is a useful format for some multi-media wais applications, but
it isn't the best or only solution