XP Mail Archive: XP> RE: Specifying the Persistence of Appmu

XP> RE: Specifying the Persistence of Appmuxed Reference Objects

From: WISSENBACH,DAVID (HP-Boise,ex1) (david_wissenbach@hp.com)
Date: Mon Jan 27 2003 - 12:29:32 EST

  • Next message: WISSENBACH,DAVID (HP-Boise,ex1): "RE: XP> RE: Specifying the Persistence of Appmuxed Reference Obje cts"

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