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

From: Eric Burger <[email-masked]>
Date: Wed, 10 Nov 2004 14:24:26 -0500

This assumes the IMAP server does the conversions.  I'll yield judgment of
the wisdom of that to the IMAP server folks.

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.

Where does the content go?  Is the result of CHANNEL a URLAUTH?  Should the
functionality be part of URLAUTH and not CHANNEL?

Thoughts from the Peanut Gallery?

> -----Original Message-----
> From: Lyndon Nerenberg [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2004 3:00 AM
> To: [email-masked]
> Subject: [lemonade] Channel updates for content conversion
> 
> 
> Folks, sorry for being so late with this. I've been dealing with
> electrical problems on the boat, which took priority. I wasn't able
> to do the update to the draft, but here is a description of how I'm
> planning to add support for content conversion.
> 
> A new CHANNELCONVERSIONS command is added. It takes the form
> 
>   tag CHANNELCONVERSIONS nstring
> 
> This command returns a list of
> supported conversion target mime types. If the nstring is NIL
> the full list of conversion targets is returned. If the string
> is non-nil it contains space separated list of top-level MIME
> types to restrict the response list to.
> 
> 
> The CHANNELCONVERSIONS response takes the form
> 
>   * CHANNELCONVERSIONS astring
> 
> where the astring contains the MIME type. There is one untagged
> response for each matching type. E.g.
> 
>   1 CHANNELCONVERSIONS NIL
>   * CHANNELCONVERSIONS "image/gif"
>   * CHANNELCONVERSIONS "image/jpeg"
>   * CHANNELCONVERSIONS "audio/gsm"
>   * CHANNELCONVERSIONS "audio/g723"
>   * CHANNELCONVERSIONS "audio/basic"
>   * CHANNELCONVERSIONS "application/pdf"
>   * CHANNELCONVERSIONS "application/postscript"
>   * CHANNELCONVERSIONS "application/x-gzip"
>   1 OK CHANNELCONVERSIONS completed
> 
>   2 CHANNELCONVERSIONS "audio"
>   * CHANNELCONVERSIONS "audio/gsm"
>   * CHANNELCONVERSIONS "audio/g723"
>   * CHANNELCONVERSIONS "audio/basic"
>   2 OK CHANNELCONVERSIONS completed
> 
>   3 CHANNELCONVERSIONS "image audio foo"
>   * CHANNELCONVERSIONS "audio/gsm"
>   * CHANNELCONVERSIONS "audio/g723"
>   * CHANNELCONVERSIONS "audio/basic"
>   * CHANNELCONVERSIONS "image/gif"
>   * CHANNELCONVERSIONS "image/jpeg"
>   3 OK CHANNELCONVERSIONS completed
> 
>   4 CHANNELCONVERSIONS "foo"
>   4 OK CHANNELCONVERSIONS completed
> 
> The CHANNEL command is extended by adding a new parameter 
> that specifies
> a conversion:
> 
>   tag CHANNEL channel-uri-list SP channel-set SP conversion-spec
> 
> conversion-spec is an nstring that specifies a single MIME type to
> convert the content to. If NIL, no conversion is performed.
> 
> If the conversion cannot be performed, a NIL response is returned for
> that item (the same behaviour as if the requested scheme failed).
> 
>   5 CHANNEL (rtsp) (1 2) audio/mpeg
>   * 1 CHANNEL 2 NIL
>   5 OK done but nothing was sent because audio/mpeg is not a valid 
> target
> 
> 
> I'm still working out issues with IMAPURL. Also, the syntax here
> gives the general sense, but the details will change when the grammar
> gets an overhaul. I'm also working on the syntax and semantics for
> how to specify the data is to be returned in-band.
> 
> --lyndon
> 
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> 

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

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 10 Nov 2004 14:24:50 -0800

--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