ietf-openproxy
[Top] [All Lists]

P work in new charter

2004-06-27 22:55:50

Hi,

        Here are a few thoughts regarding P-items in the new charter.

        I believe our biggest challenge with P remains its scope and
how P scope relates to WG work items. We had a few very important
discussions regarding P scope at the end of 2003, but they did not
result in a digestible conclusion (IMO). I am not sure we can scope P
and our P-work right now, without at least another round of
discussions.

        The two big P-questions that we may need to answer in the new
charter are:

        #1. How deep does P reach? (P scope)

            a) just an interface (language) for rule writer
               to use when configuring/selecting existing OPES
               processor actions

            b) also an interface (language) for OPES processor
               vendor, administrator, or 3rd party to write
               generic (parameterizable) OPES processor actions

            c) also an interface (language) for OPES processor
               vendor or 3rd party to write protocol-specific
               modules to be used when defining OPES processor
               actions

        #2. How deep does our charter reach? (WG work scope)

            a) just the core language (like C without the standard
               library or standard template library)

            b) also HTTP and SMTP module interfaces for selecting
               or writing HTTP- and SMTP-related actions (like
               the standard C libraries interfaces)

            c) also an interface between P interpreters and
               module/services suppliers? (like Unix or MS
               library loading conventions)


Note that the answer to the first question determines how much work we
would have to do when documenting language core. If we limit P scope a
lot, we will have to do less work. On the other hand, if we pick wrong
scope, it may be insufficient or too complex to interest vendors in
supporting it.

Is there a possibility to define a very simple P core while allowing,
in principle, feature-rich extensions to write P modules and such? Not
sure, but that could be the ideal approach. Kind of like Java applets
versus Java applications, but even more extreme. On the other hand, if
the core is really simple/basic, does it make sense to extend it at
all? Instead, it may be better to start from scratch for (a), (b), and
(c) in question #1 above!

FWIW, IRML, if further developed, would probably fit (1a) and (2b).

Thanks,

Alex.


<Prev in Thread] Current Thread [Next in Thread>