RE: AW: Using XML in OCP transport

I set-up my credibility filter to the support of DNS value added services. 
Obviously XML does not fit the job. There may be different support however. 
But was it expected is a lean, simple, stuff, robust and secure. Most of 
the initial aplications will be security. Where the flow will be authorised 
to go across, or will be trown away. Then it will probably be URL 
conversion (payment gateways could use that).
jfc



At 10:21 07/05/03, Martin Stecher wrote:


> >
> >       Would it be fair to conclude, then, that your primary reason
> > for avoiding XML in OCP is assertion #7 (the use of XML will initially
> > alienate a noticeable fraction of the existing ICAP community)?
>
> My concern is that OCP will not be successful, if implementors don't like 
> it or find it too complicated or too much work to implement.
> So yes, my primary reason is #7. But regarding new potential implementors 
> it is more an issue of assertions #2 and maybe #6, meaning that an OCP 
> implementation which takes it serious needs fully compliant XML support.
> For example: ICAP support in the Squid proxy added less than 1500 lines of 
> code. Any idea what it will take to get OCP/BEEP into Squid? As far as I 
> know there is no XML support in Squid yet.
> >
> > My reasoning is that if all of the performance-related assertions
> > below are true, then there is no performance problem with XML in OCP
> > context: all performance problems can be solved by practical,
> > real-world engineering. Such efforts are virtually always required to
> > support any new protocol efficiently anyway. If there are no
> > performance problems, then (based on you past postings), I assume your
> > primary concern is migration of existing ICAP community (i.e.,
> > assertion #7). Is my reasoning correct?
>
> I agree and never said that BEEP is not efficient.
> I am not concerned about our own implementation although it will probably 
> be somehow tricky to have an optimized XML parser for OCP and still 
> passing the compliance test that probably/hopefully The Measurement 
> Factory will come up with ;-)
> But evangelising others that this protocol is definitly the one they 
> should use or migrate to, this task could be a little harder to me. That's 
> my concern.
> Regards
> Martin
>
>
> >
> > Thank you,
> >
> > Alex.
> >
> >
> > > >   1 An OCP/BEEP implementation would parse simple,
> > > >     short XML fragments most of the time.
> > > >
> > > >   2 To be compliant, an OCP/BEEP implementation would
> > > >     have to be able to parse arbitrary XML, including
> > > >     malicious XML.
> > > >
> > > >   3 In 7 years, virtually every OCP/* agent will support XML
> > > >     for reasons unrelated to transport; that support may not
> > > >     be efficient (e.g., parsing of configuration files or
> > > >     generating logs).
> > > >
> > > >   4 It is possible to optimize parsing of simple,
> > > >     short XML fragments with known parsing goal
> > > >     (e.g., just to find the profile URIs and ignore
> > > >     everything else).
> > > >
> > > >   5 It is possible to optimize generation of simple,
> > > >     short XML fragments.
> > > >
> > > >   6 It is very tempting to use XML for OCP negotiations
> > > >     and other, mostly performance-unrelated OCP tasks _if_
> > > >     XML has to be supported for transport reasons anyway.
> > > >
> > > >   7 The use of XML will initially alienate a noticeable
> > > >     fraction of the existing ICAP community
> > > >
> > > > Does anybody disagree with any of the above assertions?
> >
>
>
>
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.474 / Virus Database: 272 - Release Date: 18/04/03