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..
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).
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.
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.
GEETHA> I need to look into those specifications ...
The second thing you mention is message-embedded rulesets. .<strip> 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.
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...
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.
Now , this may inturn throw up standardization needs for the following:
* 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.
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.
* discover an OPES service,
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.
* 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
OPES
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?
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....
*???
* 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?
* 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...
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.
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.
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?
Hope this speaks sense..
regards
Geetha