On Wed, 9 Apr 2003, Oskar Batuner wrote:
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.
Good point! I agree that it may make sense to have one draft that
covers all communications between end points and OPES processors
(tracing, bypass, etc.) If we go down that path, we need a more
appropriate name though. How about:
"Processor-to-end communications in OPES"
draft-ietf-opes-end
or
"OPES processor and end points communications"
draft-ietf-opes-end
or something like that? Does that cover all uses we know of right now?
Why the first thing that comes in mind is "bypass"? Why not
"activate", "translate", "enable-transformation"?
"Bypass" is shorter and easier to grasp with little context. :-)
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.
I agree with you rationale, but not with your conclusion/suggestion.
IMO, If there will be OCP-related tracing features, they can go into
OCP document (draft-ietf-opes-ocp) or (draft-ietf-opes-ocp-core).
IMHO OCP should be positioned as a replaceable building block.
I agree. However, a "replaceable building block" assumes some common
interface. The presence of such (undocumented) interface has an effect
on what you propose below.
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-...
I assume you meant "-ocp-". I see your reasons, but have to say that
if we go down that path, we would _also_ need application bindings for
draft-ietf-opes-end:
draft-ietf-opes-end-http
draft-ietf-opes-end-smtp
draft-ietf-opes-end-...
Instead, we could try to keep OCP as a replaceable block, but assume
(keep in mind) that whatever interface is needed for *-app-protocol
drafts would be common among all "OCPs". For example, metadata meaning
and service IDs would be common among all OCPs. This approach limits
our theoretical abilities/flexibility, but, since chances of two OCPs
long-term survival are pretty slim, we may be OK.
Comments?
Alex.