IPP Mail Archive: IPP> IPPGET Issues 1-7

IPP Mail Archive: IPP> IPPGET Issues 1-7

IPP> IPPGET Issues 1-7

From: Marty Joel (mjoel@netreon.com)
Date: Sat Aug 04 2001 - 04:31:46 EDT

  • Next message: Marty Joel: "IPP> IPPGET Issue 9"

    Hi all,

    Thought I'd add my 2 cents. Michael Sweet's comments are marked "MS>".

    Marty Joel ("<MJ>")

    "Hastings, Tom N" wrote:
    > ...
    > ISSUE 01 (see section 12): Should we use application/multiplexed
    > (draft-herriot-application-multiplexed-03.txt) which can chunk mime types
    > using content lengths, instead of multi-part/related, which uses boundary
    > strings?

    MS> How close is the multiplexed draft to being published as an RFC that
        we can actually reference?

    MS> I'd suspect that more client software will be able to handle the
        multi-part/related MIME type encoding than the new multiplexed
        encoding, however, so my vote is to stick with multi-part/related.

    <MJ> After reading the draft spec, I see no benefit of using multiplexed
    for IPP.

    > ISSUE 02: For Event Wait Mode, OK to make each successive response after
    > the first a complete IPP response, instead of just the Event Notification
    > Attributes Groups?
    >
    > Then each response looks like a complete response with its own status
    code.
    > Also complete responses might be necessary on some other transport. Also
    we
    > can move the "notify-interval" attribute back to the Operation Attributes
    > Group where it belongs, since it applies to all events being returned in
    > that response.

    MS> OK

    <MJ> OK

    > ISSUE 03: OK to clarify that the Per-Job Subscription Object and the
    > associated Job object MUST persist after the job completes (job
    completed,
    > canceled, or aborted) in the Job Retention or Job History phases (see
    > [RFC2911] section 4.3.7.2)?
    >
    > Otherwise, a Notification Recipient that is polling would not get the
    Event
    > Notification, if it polled after the job completed, but before the Event
    > Lease Time expired.

    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.

    > ISSUE 04: OK to clarify that a client or a Printer MAY disconnect the
    > underlying transport connect for any operation, including the Event No
    Wait
    > Get-Notifications operation and the Event Wait Get-Notifications
    operation
    > when the Printer isn't willing to honor the initial request or reneges in
    a
    > later response?
    >
    > So a client could keep the connection open for multiple Event No Wait
    > Get-Notifications. Before a Printer disconnects it needs to wait enough
    > time to make sure that any IPP response has had time to get back to the
    > client before disconnecting, otherwise the client might not see the
    > response.

    MS> OK

    <MJ> TCP guarantees that a send followed by a close will get through.
         I don't think the mention of waiting for the response needs to be
    stated.
         The bad wait state in TCP is when a connection is terminated (by
    either
         end) without being closed. Either end can initiate a handshaked
    close.

    > ISSUE 05: OK to add 'successful-ok-events-complete' status code for a
    > Get-Notifications response whether Event No Wait or Event Wait mode?
    > ...

    MS> OK

    <MJ> OK

    > ISSUE 06: Section 12 says: "The Printer MAY chunk the responses, but
    this
    > has no significance to the IPP semantics." Is this sufficient, or is
    > HTTP/1.1 chunking REQUIRED in order to support the multi-part/related
    MIME
    > type?

    MS> I don't think we have to make this a requirement, because a HTTP
        response with no content type has essentially the same semantics
        for a wait-mode Get-Notifications request. The only time this
        becomes an issue is if the client wants to keep the HTTP connection
        alive after the final successful-ok-events-complete message part.

    MS> Just make is RECOMMENDED, and maybe spell out the reasons why.

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

    > ISSUE 07: For Event No Wait mode, should we add a way for the
    Notification
    > Recipient to have the Printer filter out returning Event Notifications
    that
    > the Notification Recipient has already received in order to reduce the
    > duplicates (that will usually happen, else events will be lost)? Or
    should
    > we just depend on most usage using Event Wait Mode, so that there aren't
    > duplicates? It has been suggested on the mailing list that the
    Notification
    > Recipient could supply pairs of the "notify-sequence-number" and
    > "subscription-id" and the Printer would only return events with a higher
    > sequence number.

    MS> I think we have to do this - otherwise we put a greater burdon
        on the server (which has to format and send the extra events),
        the network link (which has to carry more data), and the client
        (which has to process extra events and throw old ones away.)

    MS> By putting this functionality in the server, we eliminate a lot
        of overhead at the expense of slightly greater complexity
        (basically an integer comparison for each event sent by the
        server...)

    <MJ> Better to eliminate uri searching, since Get-Subscriptions can be used
    for that.



    This archive was generated by hypermail 2b29 : Sat Aug 04 2001 - 04:35:29 EDT