OCP Core and Tracing drafts need to talk about application-independent
mechanisms. "Something(s)" need to talk about application-specific
aspects of OCP and tracing.
For example, OCP Core documents OCP messages that can be used to
communicate HTTP messages and HTTP metadata (as opaque sequences of
octets) between OPES processor and callout servers. Some other
document has to explain what HTTP metadata really means to OPES
processor and callout server when it is sent over OCP (and document
metadata format if we decide that the format itself is
application-specific).
Similarly, Tracing draft documents general rules (e.g., OPES
processors MUST/SHOULD/MAY add their IDs to the trace). Some other
document has to explain how trace entries can be added to SMTP
messages (MIME header field names and such).
It would help authors to know the set of final OPES documents so
that appropriate cross-references can be made before all documents
are written. The set can change at any time, of course.
I would like to suggest the following set. It is based on a principle
that it is better to have one application-specific document per
application. An alternative is to have one application-specific
document per application, per application-independent draft. The
former places all, say, HTTP-related things in one draft, yielding
(#Facilities + #Applications) documents
(convenient for those who implement/deploy/debug OPES _systems_ for
HTTP). The latter allows for more fine-grained, facility-specific
application drafts, yielding
(#Facilities * #Applications) documents
(convenient for those who implement/debug specific OPES facilities for
HTTP).
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
...
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
...
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?
Thanks,
Alex.