Unfortunately, I have to step up and express that this is not in scope for
the current plan of the working group.
The charter of the working group is focused on callout protocols, related
components, and AAA/security/policy issues concerning services on content.
Proxylet APIs are sort related but have not been a chartered item.
Certainly, at this point there is not a proposed API set that the working
group is working on. Separate companies have presented API documents and I
have allowed them to be placed on the web site for interested parties. BUT
these not under consideration of the (proposed) working group.
If there is enough interest I will request a non-IETF mailing list to
discuss these issues. HOWEVER, these are NOT working group documents. If
you conform to them, you are NOT conforming to anything the working has
assumed to be responsible for.
Do not be surprised by this. I expect to allow related information on the
WEB site because implementation of OPES extends beyond just knowing the
protocols. HOWEVER, only the chartered items will go though last call and
other working group phases. I will make the WEB site clear on this matter.
Michael
At 08:16 AM 11/29/2001, Patrik Johansson wrote:
> -----Original Message-----
> From: Andrew Walker [mailto:andrew(_dot_)walker(_at_)thundercrack(_dot_)com]
> Sent: Tuesday, November 27, 2001 4:35 PM
> To: patrik(_at_)lokomo(_dot_)com; ietf-openproxy(_at_)imc(_dot_)org
> Subject: Re: Can I state what my proxylet requires?
>
>
> On Tuesday 27 Nov 2001 2:28 pm, Patrik Johansson wrote:
> > Assuming there will be atlest 2 different proxylet
> service-plugin APIs, is
> > there a way in the OPES model for me to state what lib(s)
> my proxylet
> > requires to run?
> >
> > /Patrik
> Not that I've seen distributed.
>
> There needs to be an extension of OMML to include the
> relevant information
> like what libraries are required, and how to install
> libraries from the
> service bundle on deployment. Alternatively the proxylet
> bundle could include
> a seperate xml descriptor explaining what it contains, and
> how to use it.
>
> Did you have any more thoughts on descriptive API bindings so
> that the opes
> device could marshall requests to services that don't have to
> adhere to
> strict API's? This is another potential OMML extension - how
> to bind to the
> service.
Here is one thought related to the API issue:
Quite often content providers use pretty well defined content services
offered by their web hosting provider. Consider cases when a 'system cgi
lib' is provided. The host regards these services safe. No other content
services are allowed. An example of a widely used service is 'formmail.pl'.
Assume then a content provider is interested in replicating his site (a
bunch of html, gifs files and a call to formmail.pl) to a set of surrogates;
- would it be possible that the OPES model could cover such a scenario?
- will OPES then enable the content provider to state that he/she is
requiring a 'formmail.pl' lib with a specific 'formmail.pl API'?
Mapping the scenario to the model described in
draft-tomlinson-opes-model-01.txt:
1) we have a surrogate overlay
2) content service at point 1
3) requests never forwarded by surrogate (provides full service)
4) formmail.pl provides a call out (to a SMTP server)
5) lib, API in OMML?
The other way to go is of course to Prescribe the content provider to
re-write the code and use a strict OPES service-plugin API.
regards,
/Patrik
>
> Andy
>
Michael W. Condry
Director, Network Edge Technology