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

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

From: Scott Lawrence <slawrence@virata.com>
Date: Tue, 17 Apr 2001 13:49:15 -0400
Message-ID: <3ADC821B.4040309@virata.com>
To: discuss@apps.ietf.org
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 13:50:06 UTC

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