Subject: RE: protocol core now, transport/encoding later

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 17 Feb 2003 13:47:36 -0500

Alex,

thanks for the input,

General remaks,

-- good questions that u raise, however, the questions should have been
answered in the protocol requirements draft, so i suggest that we start from
there.

abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Monday, February 17, 2003 1:00 AM
> To: OPES Group
> Subject: protocol core now, transport/encoding later
> 
> 
> 
> Hello,
> 
> 	I would like to suggest that the selection of a 
> particular underlying protocol (HTTP, BEEP, SOAP, etc.) is 
> both not important and premature at this time. It is not 
> important because whatever protocol we come up with would be 
> possible to implement on top of any of those lower-level 
> protocols/APIs. It is premature because particular protocol 
> bindings and even performance would depend on minor protocol 
> details that are yet unknown.
> 
> 	The same is probably true about 
> XML-versus-text-versus-binary encoding decision. Any approach 
> will "work". We can pick the "best" later because the 
> selection will not (should not) affect the core protocol design.
> 
> I would also recommend to ignore things like 
> including/excluding version numbers or connection details 
> from certain messages. Those are just optimizations. There is 
> nothing to optimize yet. We all agree that the protocol 
> should be "simple" and "fast".
> 
> 	The following are some of the major decision points 
> that will affect the core, based on the discussion so far. 
> The items are taken from your messages, but I tried to 
> exclude questions that are already causing long discussions 
> while being, IMHO, of secondary importance. The order is 
> semi-random; these are all "major" items.
> 
> 	0) Whether there are clear/strict client-server roles or
> 	   whether it is possible for the server to send requests
> 	   to the client.
> 
> 	1) Whether the protocol is based on (request, response)
> 	   transactions or on possibly isolated messages (i.e., a
> 	   "request" may not demand/expect a response)
> 
> 	2) Whether a single request/message can solicit or
> 	   trigger multiple responses (e.g., OPES server expanding
> 	   an SMTP recipient alias into several addresses and
> 	   handling those addresses differently for the same OPES
> 	   request)
> 
> 	3) How exceptions are delivered to the other party (e.g.,
> 	   "I am not interested in seeing any more of this message")
> 
> 	4) How the "preview" feature is handled. What
> 	   the data-granularity of an OPES data transaction is (whole
> 	   message, header+tail, arbitrary range, arbitrary collection
> 	   of bytes?)
> 
> 
> Did I miss any? It would be nice to have a more-or-less 
> complete list so that one can find/propose a simple protocol 
> covering all decision points. We can then compare proposed 
> solutions and fill in the details.
> 
> 
> Thank you,
> 
> Alex.
> 
> -- 
>                             | HTTP performance - Web 
> Polygraph benchmark www.measurement-factory.com | HTTP 
> compliance+ - Co-Advisor test suite
>                             | all of the above - PolyBox appliance
>

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 17 Feb 2003 13:40:29 -0700 (MST)

On Mon, 17 Feb 2003, Abbie Barbir wrote:

> -- good questions that u raise, however, the questions should have
> been answered in the protocol requirements draft, so i suggest that
> we start from there.

Abbie,

	My understanding is that the requirements draft does not
answer those questions. Moreover, there is no clear boundary between
protocol requirements and actual decision points in protocol design.
The requirements may be very specific or quite general. We ended up
with general requirements. Fine. The requirements stage is now behind
us, and I would like to avoid going back unless absolutely necessary.
Regardless of how we answer the questions raised, the resulting
protocol is likely to satisfy the requirements draft, and that's all
we should care about. It is time for specific protocol-level work,
IMO.

If my understanding is wrong, and some of the questions are already
clearly answered by the requirements draft, please quote these
answers, and we will move on.

Thank you,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance