-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex
Rousskov
Sent: Wednesday, April 09, 2003 12:43 PM
To: ietf-openproxy(_at_)imc(_dot_)org
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