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

Keith Moore said:

"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)."

Tell me about it!!!!!  But if it doesn't use XML it isn't kewl and therefore is
unacceptable!  I proposed binary and was shot down immediately by the
"politically correct" XML!

"(however I'll confess I'm intrigued - under what conditions does a cell
phone need to send a complex document to a printer?"

Imagine an address book with icons and background images within each cell of an
XHTML table.

**********************************************
* 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)    *
**********************************************



Keith Moore <moore%cs.utk.edu@interlock.lexmark.com> on 04/17/2001 03:26:03 PM

To:   "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com
cc:   discuss%apps.ietf.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
Subject:  Re: Two new drafts: Multipart/Interleaved and Application /BatchBeep



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.

Keitt

Received on Tuesday, 17 April 2001 15:30:59 UTC