IPP Mail Archive: RE: IPP> IPPGET Issues 1-7

RE: IPP> IPPGET Issues 1-7

From: McDonald, Ira (IMcDonald@crt.xerox.com)
Date: Mon Aug 06 2001 - 13:16:44 EDT

  • Next message: Marty Joel: "RE: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing outbound channel connection only]"

    Hi Michael and Marty,

    I agree that on at least two recent IPP Fax telecons we DID agree
    that the actual Job itself (with all of its readable attributes)
    MUST persist until some brief period of time (15 seconds??) AFTER
    the last relevant Job-level Event life expires (after the last time
    that the Event could have been harvested with polling or wait-mode
    Get-Notifications response).

    IPP/1.1 badly underspecified the requirement for a Job retention
    period to support reliable job monitoring and job accounting
    applications. The PWG Job Monitoring MIB (RFC 2707) specifically
    REQUIRES that all Jobs MUST persist for at least 15 seconds
    after completion and has a default Job persistence of 60 seconds.
    It's literally impossible to specify zero (0) seconds Job
    persistence in the PWG Job Mon MIB (the integer range on the
    object syntax declaration prevents it).

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Saturday, August 04, 2001 7:25 AM
    To: Marty Joel
    Cc: ipp@pwg.org
    Subject: Re: IPP> IPPGET Issues 1-7

    Marty Joel wrote:
    > ...
    > MS> Yes, this should be the expected behavior, with the subscription
    > and job disappearing only after all events have expired.
    >
    > <MJ> The subscription object must persist, not necessarily the job
    > object. An implementation could store per-job subscription
    > objects that are not linked to job objects, and which are
    > deleted at their expiration time, even if the job object has
    > already been deleted because its job retention and job history
    > phases have elapsed.

    This prevents you from gathering the job-media-sheets-completed
    attribute after a notification that a job is complete, for example.
    I *thought* that we wanted a client to be able to query a job object
    after receiving a notification, and that job object should only
    disappear after all events referencing the job object expire.

    > ...
    > <MJ> Chinking isn't required for multipart, and I wonder if they
    > are even compatible.

    They are, but of course you'll need HTTP software that knows how
    to do it right (with the embedded content headers chunked like the
    rest of the data...

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Mon Aug 06 2001 - 13:20:25 EDT