- From: <don@lexmark.com>
- Date: Tue, 17 Apr 2001 15:12:46 -0400
- To: Scott Lawrence <slawrence@virata.com>
- Cc: discuss@apps.ietf.org
Scott: 1) It is NOT for IPP clients 2) It IS intended to help the printing of images on printers with little buffer space 3) It IS for clients that do not have "server" functionality. The client opens the connection, pushes the content and is done. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** Scott Lawrence <slawrence%virata.com@interlock.lexmark.com> on 04/17/2001 03:05:29 PM To: discuss%apps.ietf.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: Re: Two new drafts: Multipart/Interleaved and Application /BatchBeep don@lexmark.com wrote: > Just as a bit of background, the purpose, especially of mulitpart/interleaved, > was for environments (not IPP) where the client CANNOT/DOES NOT have the > resources necessary to support a server (e.g. Cell Phone) and this therefore > does a BETTER (but not foolproof) job of putting the resources in "proximity" > to where it is reference (think printing something like XHTML with images.) I don't see how this packaging issue saves resources in the IPP client - it has to muster all the components anyway to send them, regardless of what order they are sent in. Indeed, it would be easier for the sender if they were all just sent sequentially without the interleaving. The only motivation I could see for the interleaving was solving the problem of not having buffer space in the receiver to buffer the entire composite object. Perhaps I misunderstood... -- Scott Lawrence Architect slawrence@virata.com Virata Embedded Web Technology http://www.emweb.com/
Received on Tuesday, 17 April 2001 15:13:34 UTC