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

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

From: Keith Moore <moore@cs.utk.edu>
Date: Tue, 17 Apr 2001 15:26:03 -0400
Message-Id: <200104171926.PAA20363@astro.cs.utk.edu>
To: don@lexmark.com
cc: discuss@apps.ietf.org
one reason I didn't suggest the "printer fetches things on demand" model
myself was that I didn't know your requirements - other than that you 
seemed to be assuming that the document would fit into a MIME message.
there are certainly conditions under which the "on demand" model would
not work - among them being long round-trip delay conditions and
intermittent connectivity.

(however I'll confess I'm intrigued - under what conditions does a cell
phone need to send a complex document to a printer?  I can see how a
cell phone might want to dump its address book, or forward an incoming
fax, or some such.  but although these seem like potentially large 
documents, they don't seem like complex documents.  I can also see how
I might want to transmit a complex document to a printer from my palm III
to a cell phone - but the palm III is quite perfectly of speaking TCP and
acting as a server for any document that is already stored in its memory.)

But I have to wonder about problem definitions that place so many 
constraints on a solution that no reasonable solution seems possible.
It's not that such problems don't exist, it's that one gets the 
impression that the problem definition raises the bar higher than 
necessary or the solution set is constrained more than necessary.

In particular "the resources necessary to support a server" basically 
means the ability to multiplex and demultiplex data over a communications
channel, along with (perhaps) the ability to accept unanticipated 
input.  I'm not claiming that all cell phones can do this, but a device 
that cannot do this is limited indeed!  Surely the processing overhead 
associated with handling complex documents far exceeds that required
to do simple multiplexing and demultiplexing.  An environment that is so
bandwidth constrained that base64 is an onerous amount of overhead
probably shouldn't be using either MIME or XML framing either - it should 
probably be using some binary protocol that does framing, multiplexing,
and lossless data compression all at the same time (since they interact
with one another).  And intuitively, trying to make a resource-poor client 
transmit arbitrarily complex documents to a resource-poor printer sounds 
like an unrealistically hard problem.  I'd be looking for ways to place 
firm limits on the allowable size/complexity of the document.  

Realistically, unless you impose some such constraints, interoperability 
is just going to be a crap shoot anyway.

Received on Tuesday, 17 April 2001 15:26:33 UTC

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