Re: Streaming

Lee,

I absolutely agree with the concept of separating out the a generic
streamed content specifier (redirector file) from the IMAP4 extensions to
allow its use. That is going to make it easier to progress.

It is immediately clear that such a redirector file could be used in other
contexts - most relevantly within a MIME body to indicate that content
should be streamed directly from a source rather than being sent within the
message.

I am no expert on either Streaming or the Web standards, so I wonder if
there is any other work going on in the IETF or W3C in this area? It might
be nice if all that was returned was a URL pointing to the redirector file
(two levels of indirection) - although it could take a little longer for
the client to work through them and find one it could handle, if there were
several choices it might be quicker to get to the first than downloading
them all to start with.

One thing I don't want is to be stuck in the middle of a battle between
different streaming mechanisms, so let's consider making this generic
(especially if alternatives can be presented by the server) - we don't want
another "what codecs" type discussion :-). ASF could be one format
supported, but there may be other contenders (would RealNetworks support
the use of ASF?). I guess the key questions are: how much data is there to
be presented apart from the URL where it resides, and how much contention
will there be about the file format used? This is not my area, so I leave
others to comment.

I think having the ability to return several different possible streaming
sources/formats so the client can choose, rather than burdening the
protocol with the ability for the client to declare the streaming
mechanisms that it supports, will help a lot. Especially if it allows
different redirector file formats to be used for different applications,
and I see no reason why the MIME content types that can be streamed need to
be restricted explicitly to audio and video at this stage, as you suggest.
The restriction on what you can stream would be imposed by the set of
redirector file formats which have been defined and are supported by the
IMAP4 server. Whether there are any applications for a generic mechanism
beyond video and audio I do not know, but why not define something that
could be used for other things if they arise?

The biggest possible issue that I see is the security area. We need some
way of separating that out as well, I think. Internally (within the
intranet) omitting any security may be acceptable, and for some
applications a simple clear text token might be enough of a basic check,
but I am sure there are going to be requirements for challenge/response and
certificate based mechanisms for some applications, so I think we need an
extensible mechanism that will let us defer that to subsequent
specifications.

It is interesting to consider the relationship between this and the
existing MIME external body construct. In fact, another approach would be
to have the IMAP4 server present two alternate MIME bodies, one containing
the external reference (either as a URL reference to the redirector file,
or as the redirector file itself) and the other the actual content. Then
the client could then choose which one it wanted to pull from the IMAP4
server. I guess there may well be some objections to having the IMAP4
server fiddle with the contents of the message in this way, so your idea is
probably more acceptable (although it does needs new standards to be
defined). On the other hand, maybe an alternate body containing the url of
an ASF file would just work today? Opinions anyone?

Stuart