>-----Original Message-----
>From: BIGELOW,JIM (HP-Boise,ex1)
>Sent: Friday, January 24, 2003 5:14 PM
>To: WISSENBACH,DAVID (HP-Boise,ex1); 'xp@pwg.org'
>Subject: RE: Specifying the Persistence of Appmuxed Reference Objects
Hello,
>Dave Wissenbach wrote on 1/8/03
>> The MIME Application/Vnd.pwg-multiplexed document format is
>> provided to minimize memory requirements in a printer. This
>> requirement to minimize memory usage suggests that referenced
>> image data should be thrown away as soon as the images have
>> been rendered. Yet I have found no documentation to suggest
>> that this is indeed the case, ...
>>
>> If a given image is repeatedly used in the document, is the
>> image to be included repeatedly ...
>> ...
>> ... I am suggesting that persistence be
>> explicitly specified by the sending application by adding an
>> extended Content-Disposition header.
Thanks for considering this proposal.
>The January 20th meeting of the PWG XHTML-Print working group discussed
this proposal.
>Adding a reference count to the image header would indeed seem to
>tell the consumer of the multiplexed document when it can free the
>resources allocated for the image. However, it didn't seem to the
participants that a
>producer of the document would always know how many references
>would be made and still be able to locate the image next to the 1st chunk
that referenced the image.
That's partly true. The producer can't know how many references will be made
until the entire root document has been generated or parsed, which implies a
two-pass approach is needed when references are to be counted. With a
single-pass document multiplexer, the entire root document would need to be
output first. The single-pass multiplexer might be the best argument for
having a way of specifying that referenced images should persist forever, as
a robust XHTML-Print application would probably selectively discard large
already-referenced images anyways in the event of a complex document and
low-memory condition.
>Alternatives were discussed in the meeting. The alternative were having
the
>producer of the multiplexed document insert a chunk that would indicated
when
>the document would not need an image any more, or having the producer
insert some
>XHTML-Print element that would indicate when the consumer could release the
resources
>for an image. In the first case, using a chunk header to indicate when the
consumer could
>free an image won't work since the relative location of a chunk header can
not
>reliably be associated with a processing point within the document. In the
second
>case, adding new elements or processing instructions for the purpose of
indicating
>when an image's resources could be freed was not deemed to be a viable
alternative
>at this time.
I agree that modifying the xhtml document type is not a good method, given
that that the purpose of xhtml is to define an document which is independent
of the application software and rendering devices which will be used to view
that doucment.
>The group decided to reaffirm that a consumer could release the resources
associated
>with an image after the document's reference to the image was processed.
>I propose that the following paragraph be added to the Section B.2 of the
XHTML-Print spec:
>Producers and consumers of Application/Vnd.pwg-multiplexed entities, as
defined in
>[MIMEMPX], should consider each image as having one and only one
>reference. The producer should not make assumptions about the buffering
abilities
>of the consumer of an Application/Vnd.pwg-multiplexed entity and include a
copy of
>an image for each reference to it. Consumers may release the resources
associated
>with an image when the reference to it is satisfied, and are free to
optimize
>references to identical images in an implementation dependent manner.
I'd be hesitant to just recommend that a producer provide multiple copies of
each image without specifying additional detail. RFC2557 (referenced by
RFC3391) tells us how to resolve references in a compound document mandates
that each part of the multipart message have a unique ContentID and/or
unique Content-Location. The consequence of having multiple references to
the same image is then that the root xhtml document must be modified to have
a unique Content-ID or Content-Location in each of the multiple references.
At the very least, the XHTML-Print working group should modify the statement
above to more secifically recommend the method by which the root document
should be modified. Otherwise the standard breaks down at the producer to
consumer interface, because each implementer has been left to his or her own
devices and best judgement.
One other consequence of modifying the root document in the
application-multiplexed message is that this modification precludes a
message integrity check on the root document, such as an applied digital
signature on a message digest. (The digital signiture is rendered invalid by
the modification.) RFC3391 avoids the question of security consideration by
leaving this up to the XHTML-Print working group!
There are security considerations that pertain to each message of an
Application/Vnd.pwg-multiplexed entity. Those security
considerations are described by the document that defines the
content-type of the message. They are not addressed in this
document.
Allowing the modification of the root document removes the best method for
avoiding the risks of deception and repudiation for the appmuxed document
type.
My purpose in bringing up all these details is to try to solidify the
specification enough to be able to provide a robust and efficient
implementation of a demultiplexer.
Sincerely,
Dave Wissenbach
This archive was generated by hypermail 2b29 : Mon Jan 27 2003 - 12:29:44 EST