- From: <ned.freed@mrochek.com>
- Date: Mon, 16 Apr 2001 16:54:48 -0700 (PDT)
- To: Keith Moore <moore@cs.utk.edu>
- Cc: "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>, discuss@apps.ietf.org
> I only glanced at this, so maybe I misunderstood it. However... > given that the components of a multipart/interleaved aren't likely to be > usable by a traditional MIME reader anyway, I see little point in > using the MIME multipart syntax to distinguish one chunk from another. > and I don't really see a good way to build this in such a way that > existing MIME readers are likely to deal with it well. I have a much more fundamental issue with this idea. I see very little utility in this mechanism because it presumes that a client can predict when the server will need certain content. I doubt very much clients will in general be able to do this. Perhaps this would work in the extremely simple case of an XML document with a few embedded GIFs (although in such a case I'd simply embed the GIFs in the XML text itself -- there are techniques for doing this). But anything else is going to be a problem. For example, consider the case where you have a couple of GIFs that are repeated dozens or hundreds of times throughout the document. (This is a very common thing to do.) Now the client either has to assume that the server will cache the image or it has to repeat it every time it is used. The former may not work and the latter could easily increase the amount of data transferred by several orders of magnitude. Or consider the case where a more complex document structure with multiple XML parts. Cases will arise where the client has no clear idea what order the server is going to operate in. In fact you don't even know level of granularity is needed even in the simple cases. Even if you make this something the print server tells the client, I'm not even sure how it would describe its constraints. As I mentioned at the WG meeting in Minneapolis, I believe the correct solution to this problem is for the server to ask for stuff when it needs it. The obvious way to do this would be with two IPP connections, but this runs into problems with firewalls. 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 also question whether or not more code would actually be needed -- predicting when a printer will need something strikes me as quite possible a lot more code.) > I would suggest a new application/multiplexed content-type which would > be divided up into chunks, each chunk representing the next consecutive > element of some stream. Each stream could be a MIME body part, with > the normal header and content, but each stream could also be fragmented > as necessary. Ideally, the semantics would be similar to multipart > related, and it would be possible to transform an application/multiplexed > content into an equivalent multipart/related content - just that in > the first case the various components would be divided up into chunks > and multiplexed into a single body part (as far as MIME was concerned) > and in the second case the components would each appear as a separate > MIME body part within an enclosing multipart/related. These are all just syntactic details. I think the problems here are more fundamental than that. Ned
Received on Monday, 16 April 2001 20:14:14 UTC