Subject: RE: [lemonade] Channel updates for content conversion

From: Eric Burger <[email-masked]>
Date: Wed, 10 Nov 2004 21:01:10 -0500

The idea from Vancouver is there are two types of conversion.

One is IMAP server-based, most likely for non-stream media.

The other is client-driven, most likely for streaming media.  That said,
once it is in the client's hands, it can do whatever it wants.

The feeling in the room today is that server-based would be FETCH driven.
What do you think of that?

Likewise, for client-driven transcoding, the client needs a URL that it can
hand off to the transcoding server.  That would be simple URLAUTH.  What
about that?

> -----Original Message-----
> From: Lyndon Nerenberg [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2004 5:25 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: RE: [lemonade] Channel updates for content conversion
> 
> 
> --On 2004-11-10 2:24 PM -0500 Eric Burger <[email-masked]> 
> wrote:
> 
> > This assumes the IMAP server does the conversions.  I'll yield
> > judgment of the wisdom of that to the IMAP server folks.
> 
> 
> Where else would you do it? Is there another model you're thinking of?
> 
> > This does not really help for the real-time media types.  For
> > example, there are many parameters of G.726, H.263, etc. 
> that are not
> > _normally_ (but I suppose can be) conveyed as MIME parameters.
> 
> I considered this but decided to ignore it unless it was going to be
> a real issue. I think we can deal with it easily enough by allowing
> the final parameter of the CHANNEL command to incorporate the full
> syntax of the value part of the MIME Content-Type header. E.g.
> 
>  1 CHANNEL (foo) (1 2) "application/x-gzip; level=9 (an example)"
> 
> > Where does the content go?  Is the result of CHANNEL a URLAUTH?
> 
> The content goes wherever the client specifies, according to the 
> command.
> The syntax will be extended to allow CHANNEL to send data in-band by 
> specifying
> a NIL scheme. E.g.
> 
>  2 CHANNEL NIL (1 1) application/pdf
> 
> I'm still working out the protocol syntax for the response (with the 
> data).
> 
> > Should the functionality be part of URLAUTH and not CHANNEL?
> 
> I thought we decided in Vancouver that URLAUTH would have it's own
> scheme for doing conversion (through RTSP, wasn't it?).
> 
> 
> --lyndon
> 

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 10 Nov 2004 18:29:32 -0800

--On 2004-11-10 9:01 PM -0500 Eric Burger <[email-masked]> 
wrote:

> The feeling in the room today is that server-based would be FETCH
> driven. What do you think of that?

The issue I see with FETCH is the lack of an 8bit clean path. The 
converted data would still most likely require base64 encoding. I would 
like to hear Mark's opinion on this. We could structure conversion such 
that it would work with FETCH, BINARY, and CHANNEL. My concern with 
this is that it would require adding yet another capability, and as 
Alexey mentioned, IMAP is growing *way* too many capabilities. From an 
engineering standpoint I think it's better to implement in-band 
conversion in one place only. This eliminates the problems associated 
with maintaining (and debugging) multiple code paths, eliminates the 
requirement for a separate capability, and avoids a lot of complexity 
in the protocol grammar.

> Likewise, for client-driven transcoding, the client needs a URL that
> it can hand off to the transcoding server.  That would be simple
> URLAUTH.  What about that?

Yes, that sounds like what was agreed to in Vancouver (I couldn't find 
my notes with the specifics when I sent the last message).

--lyndon