Hi,
In short, I suggest to work on the following new items:
- "OCP Security" specification
- "SMTP Adaptation with OPES" specification
- "IMAP Adaptation with OPES" investigation
- RT*P Adaptation investigation
- P modules and interfaces
The above assumes that we can finish IAB, OCP Core, HTTP Adaptations,
P, and Communication drafts before rechartering. If not, the remaining
work needs to be included in the new charter.
Below are some details about each proposed work item. Except for the
P-related items, I tried to word the items for easy inclusion in the
revised WG charter:
OCP Security specification
--------------------------
Define encryption and authentication mechanism for OCP. The
resulting specification will be a compliant OCP Core extension. The
specification should reuse existing security mechanisms developed
within IETF. The specification must be application agnostic and
should make it possible for application-specific details to be
communicated via application-specific extensions if needed.
SMTP Adaptation with OPES specification
---------------------------------------
OPES WG defined HTTP adaptation mechanisms in "HTTP adaptation with
OPES" specification. SMTP adaptations are arguably as widespread as
HTTP adaptations (especially on the client-side edge), but the area
is not mature and allows for standardization to enforce OPES
principles. The SMTP Adaptation specification must provide
SMTP-specific bindings for OCP Core and Communications protocols and
may provide SMTP-specific modules for P language. The protocol work
on SMTP adaptation may require OCP Core and Communication protocol
revisions.
The working group will coordinate its efforts with the LEMONADE
working group as necessary. It is expected that OPES deliveries can
be used to assist with LEMONADE stated goal of ensuring
interoperability among e-mail enhancing services, existing e-mail
protocols, and new and traditional e-mail users.
IMAP Adaptation with OPES investigation
---------------------------------------
The working group will investigate interest within the email/IMAP
communities to support IMAP adaptation using OPES framework.
Provided sufficient interest, the working group will add "IMAP
Adaptation with OPES" specification to its work items. The protocol
work on IMAP adaptations may require OCP Core and Communication
protocol revisions.
RT*P Adaptation investigation
-----------------------------
Streaming media continues to gain popularity and IETF is making
progress with RT*P specifications. Traditional protocols such as
e-mail IMAP are being extended to support streaming media.
OCP Core and OPES Communication protocols have been designed to be
application-agnostic. HTTP and SMTP Adaptation specifications
illustrate that application-specific bindings can be built on top of
those core protocols. The possibility of providing good adaptation
support for streaming protocols is desirable but not certain.
The working group will investigate interest within the streaming
media communities to support streaming adaptation using OPES
framework. Provided sufficient interest, the working group will add
"RT*P Adaptation with OPES" and/or similar specifications to its
work items. The protocol work on streaming adaptations may require
OCP Core and Communication protocol revisions.
P modules and interfaces
-------------------------
IMO, this work item requires further discussion more than any other
item on my list. Geetha Manjunath has already posted some relevant
ideas, but we need more input. We have to make three big decisions:
- P does not have application-specific
modules or capabilities. Do we want to define them?
- P does not document the interface between P interpreter
(compiler, whatever) and P modules. This assumes that callout
service interface is identical to the module interface.
- Should we add more P features to make it possible to write
meaningful modules in P? What are the missing features here?
Should we make these decisions now? Or should we add
"make these decisions" our charter work items?
Since several adaptable protocol deal with MIME entities (HTTP, SMTP,
IMAP) it is possible that we would need some kind of "MIME Entity
Adaptation with OPES" specification to factor out things common to all
MIME-related protocols. We may want to reflect this possibility in the
charter.
I did not list "IM Adaptations" investigation in the above. Does
anybody think we should engage instant messaging community and see if
there is any interest there?
I suggest that deadlines are discussed after the work items are agreed
on.
Please object/add/comment.
Thank you,
Alex.