IPP Mail Archive: RE: IPP> Re: NOT - ISSUE 04 in the IPPGET

IPP Mail Archive: RE: IPP> Re: NOT - ISSUE 04 in the IPPGET

RE: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing o utbound channel connection only]

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

  • Next message: McDonald, Ira: "RE: IPP> IPPGET Issues 1-7"

    Hi Marty,

    IPP is a transport NEUTRAL protocol. Depending on the unique
    behavior of TCP (support for half connections) is NOT suitable
    for IPP (and thus for IPP Fax).

    IPP has a very good chance of turning up in mobile (cell/PDA/etc)
    environments in the future IF we do not screw up and force a
    particular transport mapping. Neither HTTP/1.1 nor TCP should
    be impacting the protocol neutral specification of IPP.

    Cheers,
    - Ira McDonald, consulting architect at Sharp and Xerox
      High North Inc

    -----Original Message-----
    From: Marty Joel [mailto:mjoel@netreon.com]
    Sent: Saturday, August 04, 2001 5:00 AM
    To: ipp@pwg.org
    Subject: Re: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing
    outbound channel connection only]

    Hi Tom, Ira, et al,

    Connection closing is a keep-alive issue. Why does it matter who closes
    the connection or when, as long as it is closed correctly (through the TCP
    close handshake)?

    Marty

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>@pwg.org on 08/03/2001
    05:26:12 PM

    Sent by: owner-ipp@pwg.org

    To: "ipp (E-mail)" <ipp@pwg.org>
    cc:

    Subject: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing
          outbound c hannel connection only]

    Ira McDonald was having trouble with his email, so here is his response to
    Carl Kugler comment about the Printer closing the outbound half of the HTTP
    session only.

    So OK if the IPPGET spec doesn't mention outbound channel and says just:

    The Printer in Get-Notifications MUST ALWAYS let the Notification
    Recipient close the connection, unless a long timeout expires at
    the Printer. That timeout needs to be long enough for the client to
    receive
    a response.

    Tom

    -----Original Message-----
    From: McDonald, Ira
    Sent: Thursday, August 02, 2001 08:57
    To: Hastings, Tom N; McDonald, Ira
    Subject: RE: FW: IPP> NOT - ISSUE 04 in the IPPGET spec

    Hi Tom,

    No - closing the outbound half of the HTTP session and underlying
    TCP connection is failure prone and is not even supported anymore
    by some OS libraries (TCP is the only transport protocol with
    half-connections modelled).

    The Printer in Get-Notifications should ALWAYS let the Notification
    Recipient close the connection (unless a long timeout expires at
    the Printer).

    Cheers,
    - Ira

    -----Original Message-----
    From: Carl Kugler [mailto:kugler@us.ibm.com]
    Sent: Tuesday, July 31, 2001 11:27
    To: Hastings, Tom N
    Cc: Lewis Harry (E-mail); Parra, Hugo (E-mail); Michael Sweet (E-mail);
    Ted Tronson (E-mail)
    Subject: Re: FW: IPP> NOT - ISSUE 04 in the IPPGET spec

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

    Preferably, the Printer should close only the outbound half of the
    connection. The client, reading the final response and getting the close,
    should then close the entire connection.

         -Carl



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