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

From: Eric Burger <[email-masked]>
Date: Wed, 10 Nov 2004 22:36:33 -0500

I could live with a new, foo command that retrieves content in 8-bit binary
mode with translations.

I suppose we could call it "CHANNEL" :)

That is easy for me to say.  I don't write servers, so I'll "go with the
flow."

Mark?  Alexey?

> -----Original Message-----
> From: Lyndon Nerenberg [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2004 9:30 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: RE: [lemonade] Channel updates for content conversion
> 
> 
> --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
> 

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

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 10 Nov 2004 20:05:17 -0800

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

> That is easy for me to say.  I don't write servers, so I'll "go with
> the flow."

Hey, us server authors get away easy. We don't have to maintain the 
client state machine that resolves the n*m capability graph to figure 
out how to do 'foo' with a given server instance :-)

Seriously, though, the issue of multiple capabilities and code paths is 
much more of a nightmare on the client side. I will strongly oppose any 
proposal that supports multiple paths leading to exactly the same 
result, unless there is a very good reason for it (from a protocol and 
software engineering standpoint).

--lyndon