RE: set of OPES documents

["Oskar Batuner" <batuner@xxxxxxxxx>]

> -----Original Message-----
> From: owner-ietf-openproxy@xxxxxxxxxxxx
> [mailto:owner-ietf-openproxy@xxxxxxxxxxxx]On Behalf Of Alex Rousskov
> Sent: Wednesday, April 09, 2003 12:43 PM
> To: ietf-openproxy@xxxxxxx
> Subject: set of OPES documents
>
>
[...]

>
> The set is incomplete, I only mention some documents we care about at
> this time:
>
> 	Application-independent documents:
>
> 		OPES Architecture
> 		draft-ietf-opes-architecture
>
> 		OPES Callout Protocol Core
> 		draft-ietf-opes-ocp
>
> 		OPES Tracing
> 		draft-ietf-opes-trace
>
> 		OPES Bypass
> 		draft-ietf-opes-bypass

If I understand correctly the last one is about - very limited - set
of directives. I'd suggest having a single document "OPES tracing,
notification and directives"

		draft-ietf-opes-dirs-trace

The rationale: subjects are tightly connected. There will be requests that are
tracing directives (e.g. Set-tracing-level), there will be responses to
directives
that are very close to tracing/notification info (<Via (OP:abcd> -
<Whois:abcd> - ...).
"Bypass" looks like low-granularity instruction about the desired level of
transformation.

-------------
And again - no, OPES is not evil! It is MAY be very useful for both content
producers and content consumers. Let's not focus just on ways how to
reduce possible harm, let's also look at the ways to maximize benefits. Why
the first thing that comes in mind is "bypass"? Why not "activate",
"translate",
"enable-transformation"?
-------------

If there will be OCP-related tracing features we need another document:

		draft-ietf-opes-ocp-trace

Rationale: OCP is just one recommended callout protocol. We do not exclude
usage of
other callout protocols conforming to the OPES requirements (e.g. icap-based).
Inserting OCP-related things into the document describing OPES flow will make
OCP an integral part of the OPES spec. IMHO OCP should be positioned as a
replaceable
building block.

>
> 		...
>
> 	Application-specific documents:
>
> 		OPES adaptation of HTTP
> 		draft-ietf-opes-http
>
> 		OPES adaptation of SMTP
> 		draft-ietf-opes-smtp
>
> 		OPES adaptation of FooBarP
> 		draft-ietf-opes-foobarp

For the reasons described above I'd suggest a separate set of docs:

		draft-ietf-opes-opcp-http
 		draft-ietf-opes-opcp-smtp
		draft-ietf-opes-opcp-...

>
> 		...
>
> Does the above make sense? Would you prefer the alternative (more of
> more specific drafts)? Other options like combining all
> application-independent drafts into one document?
>
> Also, given a relatively large number of related drafts, would it make
> any sense to have one short "OPES Requirements" draft that lists all
> available drafts and describes the relationship between them? Or do we
> want to repeat pretty much the same explanations in every draft
> instead? Are there similar cases in other WG?

I agree - this is an important problem. There already is certain interrelated
information scattered through different drafts. For example at some moment
Hilarie referred to the figure 2 in the policy draft to explain some
architectural
elements. I am not sure that a person studying OPES architecture will
easily find this connection. Adding a big group of documents without
proper systematization may create even more confusion.

Oskar