My Franglish tells me that processing a service is to run the program which
delivers the service. Not to remotly filter requests for that service
(which may abort, not be delivered, be negociated) through dispatch rules.
Also, that a server may only participate into providing a service. My
understanding is therefore - but again it is based upon a non native
understanding of the language - that an OPES processor is the called-out
system of servers providing the service.
Example: the Root Server System is the DNS root service processor called
out by the ISP's resolver, after it acted as a dispatcher checking on its
cached addresses. The DNS being a distributed OPES modifying the http/smtp
flow adding an IP address where the user has only entered an URL. I would
hardly say that the resolver is the DNS processor vs Name Servers.
On 21:32 02/04/03, Abbie Barbir said:
some basic terminology need to be addressed in the ocp doc.
I think we should stick with OPES Processor and Callout Server.
we can mention that they operate like a client/server, but the same
terminology as in the arch doc should be followed.
I am working my way into editing changes to the doc that will follow soon.
> -----Original Message-----
> From: Markus Hofmann
> Sent: Tuesday, April 01, 2003 3:53 PM
> To: ietf-openproxy(_at_)imc(_dot_)org
> Subject: Re: Protocol next steps
> Alex Rousskov wrote:
> > Given the above, I think we should publish as an individual
> draft to
> > give everybody enough time for a thorough review while allowing new
> > revisions to be discussed and published. Those that do not have a
> > problem with the draft becoming a WG document can treat it as such
> > immediately.
> > Submitting an individual draft should not hurt anything, should it?
> > Skipping that step would be nice, but it is not a big deal. I will
> > submit an individual draft in ~12 hours unless somebody stops me.
> > Let's move on...
> Yup, please go ahead and publish as individual draft, we
> don't want to
> delay this. We'll keep moving the draft forward on this mailing list
> with input from the entire WG, with the goal to submit the next
> version of the draft as WG document. This way, we do *not* delay
> making progress, we immediately have a valid reference point, and
> folks still have some time to carefully look at the draft.
> However, please note: Possible concerns with the content of the
> document must be brought up while we're working on the next version.
> There will *not* be a separate review time or such like once the next
> version is ready for submission (as WG document). Concerns should be
> expressed while we're on the path to the next version.
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03