Subject: OPES WG Future

From: Markus Hofmann <[email-masked]>
Date: Thu, 06 Nov 2003 20:36:19 -0500

Folks,

with all documents getting close to a stable version, it's time to 
think about our last charter item, namely

   "Consider additional OPES work such as extension to traffic beyond
    HTTP and RTSP and present new charter to IESG, or conclude working
    group."

Thoughts? Suggestions? Comments? Please post to the mailing list.

-Markus

---

From: Geetha Manjunath <[email-masked]>
Date: Fri, 07 Nov 2003 18:30:34 +0530

Hi Markus,

I feel there is quite some work that still needs to be done in the OPES
area regarding the specification of rules for filtering.. 

Using a language like 'P' (or something similar) to control activities
at the OPES can throw up several interesting opportunities...
* The P language (interpreted) would help one to define the dynamic
behaviour of an OPES processor.
* The above control to change the behaviour can be left to the
administrator to support QOS needs. However, interesting possibilities
and challenges will open up if we let 'others' define the behaviour.
* For example, if a user is able to define his/her own 'P' program
(ruleset) and send a link to that as a part of the request itself, the
request/response would get modified somewhere along the path whereever
that service is available! That is a good thing for the user! Ofcourse,
the fallback action on failure to do so would also be provided by the
user.
* Similarly, the content provider could define a P program and send it
across as one of the  response headers (in HTTP for eg). Now, depending
upon the local characteristics of the network, a specific adaptor would
be invoked. This adaptor can be provided by the content provider
himself.
[ I understand that IRML supports specification of rules by client and
content provider but there is no standard way of communicating the same
to an OPES processor...]

Now , this may inturn throw up standardization needs for the following:
* how does one specify/name an OPES service ?
* discover an OPES service, 
* authorization and authentication of the person to deploy a P program
on an OPES processor
* some work in sand boxing capability to P language itself 
* Definition of protocol specific interfaces available from P
* Specifying mandatory protocols that need to be supported by an OPES
* Way of negotiating on where a specific filter is best executed and so
on.

* If we allow the user-specified modifications (or end point requested
adaptation) to look at lower layers (IP and below), it throws up another
possibility of end nodes defining the protocol to some extent... 
* One can think of OPES processors that are able to uniformly understand
one standard language to be able to dynamically change their behaviour. 
* Are we going along the lines of standardization required for 'active
networks' - AFAIK there is no such standard as of now .. 

I guess we could use some existing protocols for some of the above needs
or modify some existing ones - but it definitely needs some serious
exploration/consensus as per my understanding...Is it worth putting
these under the purview of OPES?

Comments? Inputs?

regards
Geetha

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 7 Nov 2003 09:01:01 -0700 (MST)

On Thu, 6 Nov 2003, Markus Hofmann wrote:

>    "Consider additional OPES work such as extension to traffic
>    beyond HTTP and RTSP and present new charter to IESG, or conclude
>    working group."
>

I would like to see OPES WG finishing the work that it started. IMO,
the current charter was written to cover the next, but not the last
phase in OPES existence. There is still a lot of OPES work to be done,
and I believe we are on the right track. Frankly, I do not see any
good reasons to conclude now.

Moreover, concluding now will most likely mean death to the protocol,
tracing, and language work we have already done, at least as far as
IETF is concerned. Such forceful death would be unacceptable to me,
given the effort and already achieved results. A good time to kill
OPES has passed.

I wish the group had more active participants. However, (a) the number
of active participants is not as relevant as the results we are able
to produce (so we should concentrate on evaluating results rather than
mailing list volume) and (b) I expect noticeable increase in OPES
interest once we start marketing our results (and now we actually have
something to show people).

I will send specific work item suggestions in a separate e-mail.

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 7 Nov 2003 10:15:06 -0700 (MST)

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.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 7 Nov 2003 10:55:09 -0700 (MST)

On Fri, 7 Nov 2003, Geetha Manjunath wrote:

> Using a language like 'P' (or something similar) to control
> activities at the OPES can throw up several interesting
> opportunities...

> administrator to support QOS needs. However, interesting
> possibilities and challenges will open up if we let 'others' define
> the behaviour.

> (ruleset) and send a link to that as a part of the request itself,
> the request/response would get modified somewhere along the path
> whereever that service is available! That is a good thing for the
> user! Ofcourse, the fallback action on failure to do so would also
> be provided by the user.

> * Similarly, the content provider could define a P program and send
> it across as one of the response headers (in HTTP for eg). Now,
> depending upon the local characteristics of the network, a specific
> adaptor would be invoked. This adaptor can be provided by the
> content provider himself. [ I understand that IRML supports
> specification of rules by client and content provider but there is
> no standard way of communicating the same to an OPES processor...]

There are two distinct (IMO) things that you are mixing above. First,
is the rule authorship. I agree that there are 2.5 possible authors
here: data provider, data consumer, and intermediary administrator
acting on behalf of provider or consumer. All these authors are in
scope and must be supported by OPES. All other authors are out of
scope (but may still be supported as a side effect, of course).

We indeed have not documented authorization aspects related to ruleset
authorship versus content ownership versus hop ownership versus
service ownership. I suspect there are existing solutions here such as
IETF Policy Framework mentioned in our current charter.

The second thing you mention is message-embedded rulesets. This is the
"Active Networks" territory and we are going to alienate at least half
of IETF folks if we are not extra careful. Combining Active Networks
with OPES Adaptations in one context is likely to cause an explosion
of emotions within IAB and IESG. However, I do not think that any
direction should be banned for that reason alone. Can you provide a
couple of specific use cases that we could address with
message-embedded rulesets? Is there a real need? If we have specific
use cases in mind, we may be able to achieve what you want without
disturbing the Active Adaptation daemons.

Note that one of the P goal was to allow for embedded rulesets. Now it
is time to ask the question whether that feature is needed and, if
yes, how we can address those needs.

> * how does one specify/name an OPES service?

We tackled that when doing OPES Communication draft. OPES service can
be identified by one or more URIs. If we can agree on the URI-based
identification, the rest is probably out of P scope.

> * discover an OPES service,

This should be out of WG scope for the next round, IMO.

> * authorization and authentication of the person to deploy a P
> program on an OPES processor

The core of this problem (adaptation authorization and authentication)
is out of P scope, but, ideally, the WG should address this problem.
It is in our charter, but there are no specific deliveries.

> * some work in sand boxing capability to P language itself

Yes. And this is unrelated to embedded rulesets and other items above.

> * Definition of protocol specific interfaces available from P

Yes, we need to define HTTP and possibly other modules. I have
included that on my suggested items list as well.

> * Specifying mandatory protocols that need to be supported by an

I do not think any application protocol support can be mandatory. We
cannot require OPES to support HTTP or SMTP, for example. Or did you
mean something else?

> * Way of negotiating on where a specific filter is best executed

Sounds like a sub-problem to service identification above and, hence,
an external to P issue?

> possibility of end nodes defining the protocol to some extent...

I see no good reason to limit P or OPES adaptations to any specific
layer on a protocol level. The only question is whether this WG
should, for example, define an IP adaptation module/specification? I
doubt because we do not have the expertise and are in the wrong IETF
area (but others can do that). However, we can define a P module that
provides (read-only) IP-level information, for example. We would need
good use cases to justify such development, I guess.

> I guess we could use some existing protocols for some of the above
> needs or modify some existing ones - but it definitely needs some
> serious exploration/consensus as per my understanding...Is it worth
> putting these under the purview of OPES?

IMO, some of the things you mentioned are in OPES scope, and some
others can be in scope if you manage to convince the group and IESG
with good rationale/examples. Please see detailed comments above.

Thank you,

Alex.

---

From: "Martin Stecher" <[email-masked]>
Date: Sat, 8 Nov 2003 18:06:44 +0100

OPES WG FutureHi,

we should not conclude but recharter.

OCP core is a good concept and working well for the HTTP adaptation.
We will need some more time and work to polish this protocol when real products will have collected their experience with OCP.

It will most likely show that it is faster than ICAP/1.0 in many deployments and therefore already a valid successor.

But it can do much more which we did not yet exploit, for example,
  - adaptation of other protocols
  - agent authentication
  - transport level security

Especially I think that we should do the SMTP adaptation.
Today Email filtering is done by building a chain of MTAs which is a more serious problem as with HTTP because every agent take over responsibility for a message it received - it must not loose it, even if it crashes.
A callout protocol designed for SMTP would make filtering much easier, filtering services can concentrate on pure filtering and leave the SMTP routing stuff for other specialized programs.

Regards
Martin

  Folks, 

  -Markus

---

From: jfcm <[email-masked]>
Date: Sat, 08 Nov 2003 18:17:28 +0100

>something to show people).

I could not dedicate time to the OPES efort enought nor to come with
example enough lately because of hard time to fight for other concepts
and financiing needs. My be this will have a break and sometimes a
financing. So, I start seeing all this work as a "user" of it.

My first suggestion would be a summary. A book on OPES. Not only
to specify it, but to explain it. This would may be increase the number
of interested people and inputs. It might also help to put everything
in perspective in a real environment.

For example I am extremely interested in OPES and SMTP as I
advance on the definition and operational demands for "weemail"
(yet only in French at http://weemail.org). The idea is to use SMTP
only to carry message pointers and open header information. Mails
stay at the author mail server and is read on an as requested basis.
Great for speed and bandwidth.

Any messaging service can be used to carry that "weeheader"
(SMS, telephone, fax, written mail, radio, Teletex, etc...). This
approach looks like simplifing spamming; but puts it very unatease
as the message must be retrieved at a stable disclosed URL and
additionnal information in the header make it very easy to put
spam at such a low reading priority that it will not hurt. In this
architecture weemail policing would be brillantly supported by
OPES (if I have authorithy I could use OPES to kill access
to spam from all my domain people, in dynamilcally adding a
filtering rule: every weemail or retreiving request at a given URL
would be killed or reported as spam)

This is my ONES issue again. The future of the network is
necessarily ONES (look at VISA which nearly went broke last
week because as a ONES VISA froze 15 years ago and has
not conceptually built on its ONES to the users architecture.
Until IETF and IAB start modelzing a little bit the real network
or the NGN takes over, OPES are the next thing to ONES
we may have. Freezing OPES now would be a mistake.

Thak you Alex for all the work achieved.
But I do think again that a book explaining it would help
every one. Starting with you?
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 10 Nov 2003 13:09:26 -0700 (MST)

On Sat, 8 Nov 2003, jfcm wrote:

> My first suggestion would be a summary. A book on OPES. Not only to
> specify it, but to explain it. This would may be increase the number
> of interested people and inputs. It might also help to put
> everything in perspective in a real environment.

A book on OPES or at least a good chapter in some web architecture
book would be great. Personally, I do not have the resources to write
or publish one, but would be happy to assist others in doing so.

> For example I am extremely interested in OPES and SMTP as I advance
> on the definition and operational demands for "weemail" (yet only in
> French at http://weemail.org).

I am glad to see more use cases for SMTP adaptations. As you may have
seen, I suggested adding SMTP as the next adaptation goal for OPES
charter.

Alex.

---

From: Geetha Manjunath <[email-masked]>
Date: Tue, 11 Nov 2003 14:22:22 +0530

Hello Alex,

Sorry if my earlier (as usual hurried) mail sounded mixed up.. Actually,
I was just trying to arrive at the 'undone work' of OPES with the
starting point being 'P'. While visualizing the different ways in which
'P' can be best deployed or exploited, I found some gaps that OPES could
choose to take up..  I was not necessarily saying that 'P' should
address all the issues though.. 

Please find my specific responses inline..

> scope (but may still be supported as a side effect, of course).

GEETHA> While data provider and data consumer are the main authors as
you point out, I think the intermediary administrator can play a bigger
role than just 'acting on behalf of provider/consumer'. I am actually
referring to a case wherein the deployer of the intermediary
(/administrator) can also be a service provider - as in the case of
wireless access points in public places for connectivity .... The
wireless access provider (say in a public place  such as airports and
shopping malls) can now provide several additional context dependent web
services for business and advertising purposes. The rules that this more
powerful admin can set could be for client authorization, based on
last-leg bandwidth availability, QOS promises among others - all these
irrespective of the client and the content provider.

> IETF Policy Framework mentioned in our current charter.

GEETHA> I need to look into those specifications ...

> The second thing you mention is message-embedded rulesets. .<strip> Can you provide a

GEETHA> The specific use case is also in the same scenario as above -
the wireless access points. Just as the case of special web services
that could be deployed by the access provider, the filtering or
adaptation services could also be made available to the user - free of
charge or pay per use basis. In case of 'paid filtering services', the
client should be given a choice of whether he/she wants the filter to be
applied or not. One way of doing this, is through the request itself -
what you termed as 'message-embedded rulesets'. Some of the examples
filtering services that the client may be willing to pay for could be
video transcoding, virus filter and so on...

> identification, the rest is probably out of P scope.

GEETHA> While URI may be a way to refer to a remote callout service and
get that executed, I thought it may be required to identify a filter
service based on its functionality. This is again in the context of the
above scenario wherein a nomadic client moves from one public place to
another but wants the virus filter to be referred to with the same name
- irrespective of the actual tool used by the deployer to do the
filtering.

> This should be out of WG scope for the next round, IMO.
GEETHA> I think even this can be in the WG scope again in the above
context - wherein the discovery is limited to the filters in the local
OPES processor /wireless access point.

> cannot require OPES to support HTTP or SMTP, for example. Or did you

GEETHA> Here, I was basically coming from the angle of - if someone were
to write a 'P' program that for example works on HTTP message and were
to send it across along with the message, he better be comfortable
executing his code on the OPES nodes. I mean - rather than just assuming
that the exception handler (try statement) would take care of the
default, it would be better to send it to an OPES where he is somewhat
assured about the execution of the code without exception. For this
reason, we may have to ONE  of the following alternatives (IMO):
* all OPES processors conforming to version m.n of P must support x,y,z
protocol modules
* Reference versions of the protocol modules are provided at a location
L  - and if the OPES processor does not support one, it has to download
and execute
* Have an 'options handshake' mechanism wherein a P program can query
about the modules supported by the next upstream OPES procs and send it
over to the one that supports a given protocol....
*???

> good use cases to justify such development, I guess.

GEETHA> Typically, type of wireless network (802.11, BT,..) would be a
good input to execute certain filters. Ofcourse, use of client-IP has
become failry std i guess...  Actually, I suspect this will have heavier
implications for multi media protocols though.

> > putting these under the purview of OPES?

Hope this speaks sense..

regards
Geetha

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 11 Nov 2003 13:42:33 -0700 (MST)

On Tue, 11 Nov 2003, Geetha Manjunath wrote:

> Sorry if my earlier (as usual hurried) mail sounded mixed up..
> Actually, I was just trying to arrive at the 'undone work' of OPES
> with the starting point being 'P'. While visualizing the different
> ways in which 'P' can be best deployed or exploited, I found some
> gaps that OPES could choose to take up..  I was not necessarily
> saying that 'P' should address all the issues though..

I see! That clarifies some of the points you made. Thank you.

> While data provider and data consumer are the main authors as you
> point out, I think the intermediary administrator can play a bigger
> role than just 'acting on behalf of provider/consumer'. I am
> actually referring to a case wherein the deployer of the
> intermediary (/administrator) can also be a service provider - as in
> the case of wireless access points in public places for connectivity

Within the IETF context, we have to assume that the administrator is
acting on behalf of provider/consumer. Please note that this addresses
authorization concerns and does not preclude administrator from being
a service provider. This is one of those things were we have to be
careful to avoid raising red flags for no good reason. As long as all
provided services are authorized (one way or another) by one of the
ends, we are fine.

> .... The wireless access provider (say in a public place such as
> airports and shopping malls) can now provide several additional
> context dependent web services for business and advertising
> purposes. The rules that this more powerful admin can set could be
> for client authorization, based on last-leg bandwidth availability,
> QOS promises among others - all these irrespective of the client and
> the content provider.

Within the IETF context, OPES adaptation services would have to be
authorized by a client or content provider. Authorization is not OPES
adaptation (because it is performed explicitly by the application hop
and not implicitly on the traffic in transit). QoS can be borderline.
For example, doing traffic shaping can be done without explicit
authorization because it does not affect content. However, doing image
quality transformation has to be authorized.

Note that there could be valid unauthorized adaptations that an OPES
system can perform well in real life. We just need to be careful not
to use such cases in examples and motivation if we want IETF/IESG
approval. In other words, we are developing a peaceful nuclear
reactor. As any technology it can be misused to build an atomic bomb
and even the definition of "misuse" is unclear.

> The specific use case is also in the same scenario as above - the
> wireless access points. Just as the case of special web services
> adaptation services could also be made available to the user - free
> of charge or pay per use basis. In case of 'paid filtering
> services', the client should be given a choice of whether he/she
> wants the filter to be applied or not. One way of doing this, is
> through the request itself - what you termed as 'message-embedded
> rulesets'. Some of the examples filtering services that the client
> may be willing to pay for could be video transcoding, virus filter
> and so on...

Hmm... I understand the need for the services you mention but I am not
sure I understand how they are related to message-embedded rulesets.
If the proxy asks a user what services she wants to enable, that is
not an embedded ruleset because the rules will always reside on the
proxy (the client will not see/manipulate/embed them other than via
user-friendly interfaces). The closest thing I can think of is
creating an HTTP cookie with a ruleset so that the proxy does not have
to remember client-rules associations. Is that something you are after
here?

Or are you talking about clients that have pre-built rulesets in their
browsers and those rulesets are submitted to proxies by browsers in
hope that some proxies would support them? Kind of like "preference"
indication: "I would like my GIFs to be black and white, if possible".

> While URI may be a way to refer to a remote callout service and get
> that executed, I thought it may be required to identify a filter
> service based on its functionality.

URI is not a URL. URI can be used to identify a group of services,
including by-functionality or by-side-effects grouping. There was a
short thread about that some time ago. Please see
	http://www.imc.org/ietf-openproxy/mail-archive/msg02554.html
	http://www.imc.org/ietf-openproxy/mail-archive/msg02556.html

> This is again in the context of the above scenario wherein a nomadic
> client moves from one public place to another but wants the virus
> filter to be referred to with the same name - irrespective of the
> actual tool used by the deployer to do the filtering.

Right. URIs should do the trick well, IMO. However, I agree that there
may be a place for small message-embedded rulesets that represent
client preferences here. Something that requires non-static logic like
"if it is before 17:00, please filter porn out".

> I think even this can be in the WG scope again in the above context
> - wherein the discovery is limited to the filters in the local OPES
> processor /wireless access point.

Agreed. I just would not call it discovery. To me, it sounds a lot
more like expressing one's preferences. If we accept this as a work
item, we must learn from P3P (http://www.w3.org/P3P/) experience, I
guess. Our scope is wider/different, but available mechanisms are
probably similar.

> > I do not think any application protocol support can be mandatory.
> > We cannot require OPES to support HTTP or SMTP, for example. Or
> > did you mean something else?
>
> Here, I was basically coming from the angle of - if someone were to
> write a 'P' program that for example works on HTTP message and were
> executing his code on the OPES nodes. I mean - rather than just
> assuming that the exception handler (try statement) would take care
> of the default, it would be better to send it to an OPES where he is
> somewhat assured about the execution of the code without exception.

I do not think it is realistic to support the above given the
diversity of intermediaries out there. Also, exception handling is a
MUST-level requirement in P so the ruleset author should not worry
whether it is supported or not. She does not have to use it either --
if she does not care, the first failure will terminate the P script,
which is probably the author-intended/desired behavior in 95% of
cases.

> For this reason, we may have to ONE of the following alternatives
> (IMO):

> * all OPES processors conforming to version m.n of P must support
> x,y,z protocol modules

I cannot find a nonempty subset of protocols that would be acceptable.
For example, SMTP servers will not support HTTP and vice versa. If
course, if a ruleset is attached to an HTTP message, there are good
chances that OPES hops will support HTTP module.

> * Reference versions of the protocol modules are provided at a
> location L - and if the OPES processor does not support one, it has
> to download and execute

That should be supported already, kind of. The modules are identified
bu URIs which could be URNs (location-independent names) with known
repositories of actual module implementations for those hops that miss
a module. However, I suspect that most proxies will not download 3rd
party modules on the fly -- too risky. This approach may work well in
certain walled gardens where the modules are signed or otherwise
secured, of course.

> * Have an 'options handshake' mechanism wherein a P program can
> query about the modules supported by the next upstream OPES procs
> and send it over to the one that supports a given protocol....

That would be outside of P scope (P is a language, not a communication
protocol so it cannot have negotiations like that). Note that almost
identical functionality can be implemented by using P exceptions.
Moreover, it is unlikely that a ruleset author would have a choice of
several modules doing the same thing; either the needed module is
available or not (ignoring module-vendor differences and such).

Unless there is more P-feedback, I think we are ready for the next
step. I will try to summarize in the next e-mail.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 11 Nov 2003 13:46:51 -0700 (MST)

Geetha,

	IMHO, there is a lot of good stuff in what you are proposing.
The next step would be to phrase your favorite items as proposed
working group actions and specific deliverables for the new WG
charter, I guess.

While doing that, please do not count on much legwork support from
other working group members. There are probably less than 2.0
person-equivalents available on a daily basis to assist you right now.
Thus, be prepared to lead the work (which I think you are) and limit
your proposal to the most interesting/essential items that you want to
work on.

My understanding is that the working group would then review your
proposal and try to reach consensus on what to include in the revised
charter.

Thank you,

Alex.