After reading RFC-XXXX and hacking a quick UA (well, at least the
receiving half of a UA) that at least understands most content types,
I have some comments; sorry if these subjects have been discussed to
death earlier (I've only seen the last ~2.5 Megabytes of this list).
1. Drop multipart/parallel.
It's cute, but sufficiently ill-specified to be fairly useless. It
doesn't specify any kind of synchronization between the parts, so for
synchronized sound and images, the video type would be better. About
the only use I can see for it is to play a sound in parallel with an
image or some text, but I suppose a friendly user agent can play any
voice mail in the background, letting the user go on to the next part
(I felt pretty frustrated when the first version of my UA started
playing the several-minutes-long sound sample in one of the demo
messages and locked the keyboard.) BTW, my UA also displays images in
the background. Most other content types can only be handled by the
user one by one anyway (text larger than a page has to be paged,
AUTOMAIL programs have to be interacted with, etc.)
2. Add multipart/archive.
With this I mean some kind of official support for the use of
multipart messages to (eventually) replace "shar" as the favorite
source transfer mechanism. Multipart messages solve all the problems
that shar solves, without limiting its use to UNIX. All we need is a
convenient way to automatically unpack a nested multipart archive as a
directory (when the user tells the UA to do so). The filename of each
part can be specified in the Content-description, perhaps using some
special convention to also indicate the "mode" (for UNIX use). Nested
multipart parts form subdirectories.
While without a subtype devoted to this one could still use the
multipart/mixed format for this purpose, a standard will improve
interoperability, and (I hope) encourage people to stop using shar.
(There is some fine print in the description of the BINARY type that
suggest it is the proper category for sources -- surely this wasn't
intended?)
3. I agree with the audio/basic proposal.
It's important to have the basic parameters of the sound in the same
file as the data after undoing any base64 encoding.
I don't want to limit the encoding types to u-law. Reasonable-quality
conversions between various encodings are not difficult (I do this all
the time), so I see no reason why a UA shouldn't be able to play
sounds that are encoded in a different way than /dev/audio expects.
Allowing several encodings avoids loss of quality if sending and
receiving station are compatible. Type 1 (unencoded u-law) is of
course most widespread, with all those sparcs around.
4. I vote for a required checksum (or hash code or whatever) in BASE64.
It could even be the last two bytes of data -- most data describes its
own length anyway somehow, and two extra bytes in the file won't hurt it.
Requiring a checksum NOW makes it more robust against manual
manipulation of BASE64 data by people without conforming UA's. E.g.,
if I were to receive a bunch of message/partial type messages today, I
would have to manually concatenate the parts and remove the headers --
it's easy to make mistakes there.
BTW, has anybody considered yet what a checksum means for BASE64 that
uses portable end-of-line markers? Maybe we should consider dropping
those?
--Guido van Rossum, CWI, Amsterdam <guido(_at_)cwi(_dot_)nl>
"*Nobody* expects the Spanish Inquisition"