P work in new charter

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.