Subject: Re: HTTP/OCP: OPES-Via to replace OPES-Processor and OPES-Service

From: Alex Rousskov <[email-masked]>
Date: Mon, 17 Nov 2003 17:28:42 -0700 (MST)

This issue prevents us from issuing WG last call on IAB draft and
is a dependency between IAB draft and HTTP Adaptations draft.

I will be making the OPES-Via modifications described below in both
drafts:

    - delete OPES-Processor and OPES-Service headers

    - add OPES-Via header that contains trace entries for
      OPES system, OPES processor, and callout services.

    - leave OPES-System header that contains OPES system
      identifiers only. These identifiers will be repeated
      in OPES-Via. This repetition will establish
      boundaries between entries for two OPES systems
      (consumer and producer) in a detailed OPES-Via trace.

Please comment or object ASAP.

Thank you,

Alex.

On Fri, 24 Oct 2003, Alex Rousskov wrote:

>
> The current HTTP/OCP draft defines OPES-System, OPES-Processor, and
> OPES-Service to support tracing requirements of the Communications
> draft. OPES-System is mean to contain a URL that a user will access to
> get high-level information about what is going on. The OPES-Processor
> and OPES-Service headers are to specify OPES agents that touched the
> application message.
>
> OPES processor and service are not a well-defined thing. A processor
> can be a service at the same time, and vice-versa. It is possible that
> there will be a third kind of entity that would need to be traced in
> the future (proxylet or whatever).
>
> Having two headers makes it impossible to determine the order of
> agent invocations. Was the second processor or the second service
> applied first?
>
> Header names are singular but may contain multiple agent entries.
>
> To solve all of the above problems, I suggest that we use a
> single, more general header: OPES-Via.
>
> I will make documentation changes unless there are objections or
> better ideas.
>
> Alex.
>
> P.S. OPES-System is not perfect either, especially given the
>      fact that there could be two systems applied to the
>      same message. In that case, there is no way to match
>      OPES-Via entries with OPES-System entries.
>
>      We could put everything into OPES-Via, I guess, but that
>      would make it more difficult for end-user to troubleshoot.
>      One the other hand, do we really expect dumb end-users
>      to trouble shoot (the smart ones will figure it out)?
>

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 18 Nov 2003 09:41:58 -0500

>       (consumer and producer) in a detailed OPES-Via trace.

Sounds good to me.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 18 Nov 2003 14:51:05 -0700 (MST)

I have updated HTTP Adaptations draft accordingly:

	http://www.measurement-factory.com/tmp/opes

Martin has not reviewed my changes yet.

Alex.

---

From: "Martin Stecher" <[email-masked]>
Date: Thu, 20 Nov 2003 21:43:50 +0100

Hi Alex,

> Other OPES agents MUST use the OPES-Via header if they add their
> tracing entries. All OPES agents MUST append their entries.

I stumbled over the second sentence. To me it sounds that all agents MUST
add their entries but what you want to say is that if an agents add its
entry,
it MUST append at the end of existing lists and not replace or insert
somewhere else

> If an OPES-Via header is used in the original application message, an
> OPES System MUST append its entry to the OPES-Via header. Otherwise,
> an OPES System MAY append its entry to the OPES-Via header.

Again not so clear to me. "Otherwise" is if there is no OPES-Via header in
the
original app message, so how can someone append its entry to something that
does not exist. So how about:
Otherwise, an OPES System MAY add an OPES-Via header with its entry.

Typo in next sentence:
> If an
> OPES System is using both headers, it MUST add identical trace
> entries except it MAY omit some or all trace-entry parameters from
> the the OPES-Via header.
Double "the".

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 20 Nov 2003 14:19:18 -0700 (MST)

On Thu, 20 Nov 2003, Martin Stecher wrote:

> I stumbled over the second sentence. To me it sounds that all agents
> MUST add their entries but what you want to say is that if an agents
> add its entry, it MUST append at the end of existing lists and not
> replace or insert somewhere else

You are right, this MUST should be reworded to indicate the latter
meaning.

> > If an OPES-Via header is used in the original application message,
> > an OPES System MUST append its entry to the OPES-Via header.
> > Otherwise, an OPES System MAY append its entry to the OPES-Via
> > header.
>
> Again not so clear to me. "Otherwise" is if there is no OPES-Via
> header in the original app message, so how can someone append its
> entry to something that does not exist. So how about: Otherwise, an
> OPES System MAY add an OPES-Via header with its entry.

Sounds good to me. It is still not perfect because, technically, one
can have an empty OPES-Via header. Your version is better though.

> > entries except it MAY omit some or all trace-entry parameters from

Ack.

Thank you,

Alex.

> --------------------------------------------------------------
> This mail has been inspected by Webwasher - leading technology
> for E-mail and Web Security.
>
> Webwasher - keeping your Web clean!
> --------------------------------------------------------------
>