Hi Marty,
Because I was sloppy, we're still speaking at cross purposes.
The IPP protocol is ENTIRELY specified in transport-neutral manner
in IPP/1.1 Model and Semantics (RFC 2911). There are no transport-
specific behaviours at all.
The binding of the IPP abstract protocol to HTTP/1.1 and TLS/1.0 and
TCP is specified in RFC 2910. Here, there are no operation-specific
behaviors.
There isn't anywhere in the IPP specifications for the behaviour of
TCP under TLS under HTTP to be discussed with respect to the
behaviour of an operation and adding one is bad idea.
Cheers,
- Ira McDonald
-----Original Message-----
From: Marty Joel [mailto:mjoel@netreon.com]
Sent: Monday, August 06, 2001 2:21 PM
To: ipp@pwg.org
Subject: RE: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing
outbound channel connection only]
Hi Ira, et al,
That's just my point. What we've done with the design of ippget recently
is to define wait mode as a single IPP request which is followed by
multiple IPP replies, until a reply indicates that there will be no more
replies. That really has no direct bearing on the transport protocol. We
have, however, decided that to make it easy for the client to know when it
has received the end of each reply, that when using HTTP, the server will
return each IPP reply in a (HTTP multipart) part. This should really only
be mentioned in the implementation portion of the ippget spec. Within that
implementation portion of the spec, it may also discuss connection closing,
although I don't think that is necessary, since either side should be able
to close a keep-alive type HTTP connection at any time (by using TCP's
close handshaking).
Regards,
Marty Joel
"McDonald, Ira" <IMcDonald@crt.xerox.com>@pwg.org on 08/06/2001 10:09:02 AM
Sent by: owner-ipp@pwg.org
To: "'Marty Joel'" <mjoel@netreon.com>, ipp@pwg.org
cc:
Subject: RE: IPP> Re: NOT - ISSUE 04 in the IPPGET spec [Printer closing
outbound channel connection only]
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 - 19:06:42 EDT