Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing

From: Graham Klyne <[email-masked]>
Date: Thu, 23 May 2002 00:55:03 +0100

1-5 seem to broadly reflect my stated views.

Regarding 6:  contrary to the wording below, I now see, and agree, the 
desirability of a standard callout protocol, namely multivendor 
interworking between data dispatchers and service processes.

#g
--

At 09:58 AM 5/22/02 -0400, Abbie Barbir wrote:

>Graham and all,
>
>I am providing a summary of the current position and feedback.
>This will be points that we try to get agreement on.
>
>1. endpoint-user must be able to access OPES diagnostic
>    information using legacy s/w.
>2. have no problem with protocol extensions being available to
>    facilitate access to the information.
>3. not opposed to using In-band information even if it means extensions
>4. keeping a log could be quite sufficient
>5. having out of band access from one endpoint or the other is a far better
>    outcome than having none
>6. (From mark baker) No need to standardize on a callout protocol.
>
>Here I propose that we start a new thread where each point is discussed 
>and get solved.
>
>abbie

-------------------
Graham Klyne
<[email-masked]>

---

From: Mark Baker <[email-masked]>
Date: Thu, 23 May 2002 12:55:49 -0400

> interworking between data dispatchers and service processes.

I agree that multivendor internetworking is critical.  I just believe
that it should be achieved by agreeing on the "flow" protocols.  For
example, by building a language translator as an HTTP proxy.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               [email-masked]
http://www.markbaker.ca        http://www.idokorro.com

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 23 May 2002 13:36:36 -0400

> example, by building a language translator as an HTTP proxy.

This implies that requests AND responses will travel through the "box" 
the language translator is running on, which is not really required 
since it cares only about the responses. With a callout protocol, you 
vector out only the responses, letting the request go through directly.

-Markus

---

From: Mark Baker <[email-masked]>
Date: Mon, 27 May 2002 12:28:55 -0400

> vector out only the responses, letting the request go through directly.

Really, a callout service only cares about responses?  So where in the
architecture, would a service that translated outbound documents go?
Why is a response-based service special?

MB

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 27 May 2002 13:14:04 -0400

> Why is a response-based service special?

There are services that care only about responses, services that care 
only about requests (or outbound messages), and services that care 
about both.

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 27 May 2002 13:20:55 -0400

> Why is a response-based service special?

Hm, may this did not become clear... you cannot only vector out 
responses, but also request, of course, or both, of course.

If a service only cares about the response, you vector out only the 
response. If a service only cares about the request, you vector out 
only the request. If a service cares about both, you vector out both 
(which, in this case, could also be achieved via proxy).

-Markus