This is a multi-part message in MIME format.
--------------99B48168D1A685467C47661C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I think Zhi-Hong has raised a very valid concern here, one that we
should address in a clean and unambiguous manner within IPP.
If IPP allows multiple posts (requests) in which the client is
expecting to receive multiple responses, then IPP should be
clearly defined to do one (and only one) of the following:
a) Ensure the order of responses is *exactly* in the same
order as the requests, or
b) Define and force mandatory usage of a client-specified
transaction id (included as part of a request) that the
server attaches to all responses. The transaction id
would be considered completely opaque to the server (ie,
no semantic meaning whatsoever).
If we wish to provide maximum performance potential, then the
second choice would be the second (b) option. Adding such a
transaction id wouldn't add that much "baggage" to the protocol.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
--------------99B48168D1A685467C47661C
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from lists.underscore.com (uscore-2.mv.com [199.125.85.31]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id KAA21797; Fri, 21 Nov 1997 10:14:15 -0500 (EST)
Received: from localhost (daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA15312; Fri, 21 Nov 1997 10:14:13 -0500 (EST)
Received: by pwg.org (bulk_mailer v1.5); Fri, 21 Nov 1997 10:12:00 -0500
Received: (from daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id JAA14699 for ipp-outgoing; Fri, 21 Nov 1997 09:58:26 -0500 (EST)
Message-Id: <199711211447.JAA06431 at devnix.agranat.com>
To: zhi-hong at zeno.com (Zhi-Hong Huang)
cc: ipp at pwg.org
Subject: Re: IPP> Processing Algorithm
In-reply-to: <3474D9D4.9DDD1B1 at zeno.com>
Date: Fri, 21 Nov 1997 09:47:39 -0500
From: "Scott Lawrence" <lawrence at agranat.com>
Sender: ipp-owner at pwg.org
Content-Type: text
>>>>> "ZH" == Zhi-Hong Huang <zhi-hong at zeno.com> writes:
ZH> Since client may POST several IPP requests on a single HTTP 1.1
ZH> connection, if the server replys before consuming all the data
ZH> the client sends, it would be difficult for the server to locate
ZH> where the next message starts.
I'm not entirely sure that I'm addressing the right concern here,
but... an HTTP/1.1 server can detect the end of an entity body in
any of three ways: a Content-Length header, Transfer-Encoding:
chunked, or a Multipart encoding that is self-descriptive.
It is true that an HTTP client using persistent connections (either
1.1-style or the Netscape Keep-Alive style) must keep track of the
order of requests, and the server must preserve that order in
sending responses as there is no transaction identifier.
Did that answer your question?
--
Scott Lawrence EmWeb Embedded Server <lawrence at agranat.com>
Agranat Systems, Inc. Engineering http://www.agranat.com/
--------------99B48168D1A685467C47661C--