At 6:13 PM +0700 29/1/03, Robert Elz wrote:
| 2. Enhance the existing IMAP4 message retrieval protocol to satisfy
| the requirements for streaming playback of multimedia content.
What a horrid idea? How do "streaming playback" and "message retrieval"
possibly fit together at all?
Voice Mail. A number of ISDN access devices without significant local
storage are capable of converting an incoming call to an SMTP stream
on the fly and spooling it to a mail server. Pretty much everyone who
is implementing this is doing it the same way, so there's no need for
the IETF to step in.
Retrieval is then easy for someone with an IMAP client on their primary
system if it's capable of playing audio, but it's more complicated if
the user wishes to retrieve the message from a phone. Currently there
are a number of different approaches to this problem - the ones I have
come across include:
1) An application between the IMAP server and the voice gateway that
retrieves the whole message, then delivers it via RTSP at the correct
rate.
2) Some other interface directly to the mail store that bypasses the
IMAP server.
3) The voice gateway directly accessing the IMAP server and plays with
TCP window sizes and delaying acknowledgements to limit the amount of
the voice mail stored in memory in the voice gateway at any point in
time.
In cases 1 & 2, almost always some form of proprietary signalling
protocol then runs between the access device and intermediate
application (1) or the message store (2).
My view is that whenever there are different groups trying to solve the
same problem and coming up with different, non-interoperable solutions
based on IETF-defined standards then it really is in the IETF's court
to at least consider some form of standard or informational RFC.
Lemonade seems to fit the bill.
Is this yet another attempt to pervert
a protocol into meeting some other quite unrelated need, for the sole
purpose of getting through firewalls or similar? Drop this nonsense.