Don,
The entire MIMEPLEXED document could indeed be digitally signed. What I was
thinking about was a case where a document digitally signed by Bill (perhaps
a promissary note) was being viewed by Fred on his PDA. If Fred multiplexed
the xhtml print document digitally signed by Bill and sent this to Fred's
bank to be printed, as evidence of collateral, any change by Fred to the
root document, even in the references, would invalidate Bill's digital
signiture. So Fred could originate a digitally signed mimeplex document, but
Fred couldn't package Bill's document in mimeplex (assuming multiple
references).
With regards to the second statement--if we use RFC2557 as the standard for
resolving URLs in compount documents, we don't ever need Content-ID, as
RFC2557 allows the use of Content-Location in both the appmuxed header and
in the image sub-documents. (RFC3391 seems to suggest the use of RFC2557 for
the intricate details of resolving references in the root document.) If we
(the members of the pwg) implement to RFC2557 then a web document
constructed with relative URLS so as to be portable can be easily
multiplexed, as all the relative references resolved to
thismessage:/image.jpg, etc. Of course Content-ID can and should be
supported.
I advanced the proposal to explicitly specify reference count or persistence
to try to preserve the integrity of the root document, and avoid
modification to the root document, while also preserving the goal of
accomodating printers with limited memory. If I fail to persuade the printer
working group to adopt this change (or have I already failed in this
regard?) that's OK--the most important thing for the success of the standard
is clarity of the specification and uniformity of the implementations.
Dave
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Monday, January 27, 2003 1:49 PM
To: WISSENBACH,DAVID (HP-Boise,ex1)
Subject: Re: XP> RE: Specifying the Persistence of Appmuxed Reference
Objects
David:
I'm confused by your claim that the document must be modified. The producer
of the document would have to produce it knowing that each and every
reference to a repeatedly used image would have to have an image chunk in
the stream. The producer would have to create the unique content-ID that
referred to that image. The producer could then create any kind of digital
signature knowing the exact stream of both XHTML-Print and the
mime-multiplexed documents. This ONLY applies when the entire content of
packaged in the mime-multiplexed format.
If the XHTML-Print is sent NOT using that format and any images are obtained
by the printer based on a URL contained within the XHTML-Print then there is
no need for content-ID on the image reference.
*******************************************
Don Wright don@lexmark.com
Chair, IEEE SA Standards Board
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org
Director, Alliances and Standards
Lexmark International
740 New Circle Rd C14/082-3
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
*******************************************
"WISSENBACH,DAVID (HP-Boise,ex1)" <david_wissenbach@hp.com>@pwg.org on
01/27/2003 12:29:32 PM
Sent by: owner-xp@pwg.org
To: "BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>, "'xp@pwg.org'"
<xp@pwg.org>
cc:
Subject: XP> RE: Specifying the Persistence of Appmuxed Reference
Objects
>-----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 - 16:19:50 EST