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

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 17 Feb 2003 06:00:40 -0500

hi,

I will come up with a list this week, it will be a summary of the results.

abbie

> -----Original Message-----
> From: jfcm [mailto:[email-masked]] 
> Sent: Monday, February 17, 2003 5:11 AM
> To: OPES Group
> Subject: Re: protocol core now, transport/encoding later
> 
> 
> At 06:59 17/02/03, Alex Rousskov wrote:
> >         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
> 
> May I suggest that the OPES web master maintains a list on 
> the site where 
> we could list these ideas. Then we could discuss their 
> aggregation into a 
> minimum non conflicting list much more easily?
> 
> At this stage it could only be to paste them on an Excel page 
> and to give 
> them a number. The target would be first to see the one we 
> really need, the 
> ones wich means the same thing, etc.
> jfc
> 
> 
>

---

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 18 Feb 2003 04:57:23 -0500

hi, 

see A. beck response regarding the requirement draft.

on the otherhadn, I agree with you that the resulting protocol better meet
the requirement draft (at least for most of the cases)

abbie

> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Monday, February 17, 2003 3:40 PM
> To: OPES Group
> Subject: RE: protocol core now, transport/encoding later
> 
> 
> 
> 
> 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
>