Subject: RE: AW: Using XML in OCP transport

From: jfcm <[email-masked]>
Date: Wed, 07 May 2003 18:44:11 +0200

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

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 7 May 2003 11:25:25 -0600 (MDT)

On Wed, 7 May 2003, jfcm wrote:

> I set-up my credibility filter to the support of DNS value added
> services.  Obviously XML does not fit the job.

Why not? If XML is only used for BEEP channel management and OCP is
optimized to reuse existing session channles, then I do not see how
XML [performance] prevents OCP from adapting DNS. Can you clarify?

> 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

How does limited use of XML in OCP prevent the above adaptations?

Thanks,

Alex.

---

From: jfcm <[email-masked]>
Date: Thu, 08 May 2003 00:25:12 +0200

>XML [performance] prevents OCP from adapting DNS. Can you clarify?

Sure.
complexity, bandwidth, delay, size of the transported information.
Security. I do not say any need for XML in the current needs I cover
(DNS calls, acess redirection, IDNA, authorization of access).

Just security precludes using an existing library without reviewing
entirely. etc.

>How does limited use of XML in OCP prevent the above adaptations?

What do you name limited use of XML? In the type of exchanges
I consider (returning an ACE label for an IDN) can you quanty the
overhead?

The OPES procesor (your wording) filters the proposed DNs and
send them to be rewriten to an OPES server (may be 10 to 15
characters). They are worked on for may possible services :
- conversion in ACE label
- conversion of an ITLD
- permitted access
- security check/taping/statistics (cf. Cisco current reponse to
   tapping legislations)
- etc ...
The new DN is returned. may be 10 to 25 characters so it
may proceed toward the nameserver.

Another application of interest: antispaming strategy. An OPES
processor an MTA calls the sending UA to check the validity
of the mailid (to check the origin) and permits the mail to proceeed.
Sends the MailID (may be 10 to 50 chars) and receives a Y/N.

Another application of interest a cookie server. I load the
data there, not on the caller's machine. When a cookie is called
my OPES processor captures the call and reroute to my cookie
server. Very low, well established, non XML processes.

I have nothing aganst XML when it brings a plus. I just say it
isnot always the case. So it should not be mandatory.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 7 May 2003 22:06:09 -0600 (MDT)

> (DNS calls, acess redirection, IDNA, authorization of access).

XML messages for BEEP channel management are not complex, are not
significantly bigger than any other encoding we can come up with, and
do not cause extra delays. Moreover, they are used relatively
infrequently compared to OCP messages. I agree that our needs do not
require XML. However, we may benefit from BEEP and BEEP requires
limited use of XML.

> Just security precludes using an existing library without reviewing

I am not buying this argument because
(a) you do not have to use any libraries you do not trust
(b) are you also reviewing your compiler code and processor firmware
    entirely?

> What do you name limited use of XML?

BEEP channel management. I posted some examples and the BEEP RFC
contains a lot more information, of course. Marshall has pointed out
many times by now that mainstream BEEP exchanges do not have to use
XML, they can use whatever MIME type we want, including new ones.

> In the type of exchanges I consider (returning an ACE label for an
> IDN) can you quanty the overhead?

This type of exchange does not have to use XML at all as long as BEEP
sessions and channels were established prior to the exchange (to
handle many exchanges, presumably). We are working within a
connection-oriented framework (for OCP, not necessarily for the
application being adapted).

> may proceed toward the nameserver.

That's fine. OCP messages do not have to use XML.

> processor an MTA calls the sending UA to check the validity of the
> mailid (to check the origin) and permits the mail to proceeed. Sends
> the MailID (may be 10 to 50 chars) and receives a Y/N.
>
> Another application of interest a cookie server. I load the data
> there, not on the caller's machine. When a cookie is called my OPES
> processor captures the call and reroute to my cookie server. Very
> low, well established, non XML processes.
>

And it is not, not for OCP messages. XML is only mandatory for BEEP
channel management and, since we assume long-lived OCP connections,
the overhead of channel establishment can be spread across
many application messages being adapted.

Alex.