W3C home > Mailing lists > Public > ietf-discuss@w3.org > April 2001

Re: Two new drafts: Multipart/Interleaved and Application /BatchBeep

From: <don@lexmark.com>
Date: Tue, 17 Apr 2001 15:12:46 -0400
Message-Id: <200104171912.PAA22522@interlock2.lexmark.com>
To: Scott Lawrence <slawrence@virata.com>
Cc: discuss@apps.ietf.org


1) It is NOT for IPP clients
2) It IS intended to help the printing of images on printers with little buffer
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

Scott Lawrence      Architect            slawrence@virata.com
Virata       Embedded Web Technology    http://www.emweb.com/
Received on Tuesday, 17 April 2001 15:13:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:11 UTC