ietf-openproxy
[Top] [All Lists]

RE: AW: Using XML in OCP transport

2003-05-07 21:06:08

On Thu, 8 May 2003, jfcm wrote:

On 19:25 07/05/03, Alex Rousskov said:
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?

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).

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
entirely. etc.

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?

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).

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

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).

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.

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

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.

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.