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

All:

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.)
Also, some of these environments are NOT tcp.  Don't argue with me about whether
or not the Cell Phone can afford to include a server so the printer can get the
image as it needs it.  This is one of the underlying requirements based upon
what functions can afford to be included by the manufacturer of these devices.
The printer guys didn't make up the rules.... we just have to live with them and
solve the problems based on them.

Oh and by the way, we also didn't decide the base protocols either so when the
protocols chosen don't do what is necessary, we have to solve the problem with
packaging.  Because of bandwidth issues (again, think non-TCP, non-internet,
non-megabit pipes), the 33% inefficiency of base64 encoding with the XHTML/SOAP
is also not acceptable.

**********************************************
* 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
01:49:15 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



Dave Crocker wrote:

> At 04:54 PM 4/16/2001, ned.freed@mrochek.com wrote:
>
>> A better approach would be to use BEEP's multiple
>> session capability -- the client could send the control document over
>> and the
>> server could request things from the client on a different channel.
>> The result
>> is a single connection, just in time data delivery, and no need for
>> the client
>> to have to try and predict when the server will need something. The
>> disadvantage is that it's a new protocol, but frankly, if this problem
>> is worth
>> solving we should not be afraid of a new protocol to solve it.
>
>
> I like this description quite a lot.
>
> It also sounds like exactly the same task that a Web client has when
> rendering a web page...

I agree (as I did in person in Minneapolis) with Ned that the
fundamental problem is that of just-in-time delivery, and the sender
cannot know what that means.  For example, in looking at our server
logs, we do not find that browsers all request the images for a
given HTML document in the same order.

These drafts were motivated by the buffering problems of an IPP
printer, but similar problems would be faced by any device that must
combine mulitple components to produce a whole (wireless PDA
displaying an alert with a specific font and a graphic).  Far better
is to provide a means of doing bidirectional requests.

IPP already incorporates print-by-reference, so having the sender
incorporate references to objects it is prepared to provide through
a special-purpose HTTP server is not much of a stretch - putting the
sequencing control of them into the renderer where it belongs.

The HTTP Upgrade mechanism could be used to switch the HTTP/IPP
connection to BEEP/xxx for any value of xxx (including HTTP, even if
that would give people alergic reactions).

--
Scott Lawrence      Architect            slawrence@virata.com
Virata       Embedded Web Technology    http://www.emweb.com/

Received on Tuesday, 17 April 2001 14:21:32 UTC