If other protocols than http are supported my "filter" is "can the DNS be
supported". The application being the missing IDNA solution for
Internationalized TLDs.
I am sure that SOAP is quite heavy/slow to support that. The architecture
yet is simple: The OPES processor receives a querry with an unkown TLD. It
OCP it to a DNS.2 server which responds both the meaning of the TLD and the
IP addresses of its zone server for the calling OPES Processor. The Path
leaves the calling party to decide to use the proposed IP address (lcoal
TLD) or not.
jfc
At 18:46 22/04/03, Abbie Barbir wrote:
Markus,
u have to deal with this option anyway.
Once u define generic OCP you will end having OCP over XXX over yyy over
zzz etc...
Abbie
> -----Original Message-----
> From: Markus Hofmann
[<mailto:markus(_at_)mhof(_dot_)com>mailto:markus(_at_)mhof(_dot_)com]
> Sent: Tuesday, April 22, 2003 11:52 AM
> To: ietf-openproxy(_at_)imc(_dot_)org
> Subject: Re: SOAP and OCP
>
>
>
> Abbie Barbir wrote:
>
> >> 1. SOAP is not a transport protocol. Would you
> >> require a specific transport protocol to
> >> be used if OCP is implemented using SOAP?
> >> For example, would you require that BEEP/TCP and
> >> only BEEP/TCP is used under SOAP?
> >
> > Yes, but there are bindings defined for SOAP (like HTTP,
> BEEP ?). No
> > we will not require specific bindings. We have agreed that this OCP
> > draft basically define metadata/state machine for OCP and that
> > bindings will be defined later. IF we use SOAP, then SOAP
> can have its
> > own bindings. This way we define SOAP/OCP and then SOAP
> over ... can
> > be defined by anyone else.
>
> I'm not convinced that this would be an attractive option, since it
> opens up again the issue of interoperability. I bet we'll see vendors
> implementing "OCP over SOAP over A" and other vendors implementing
> "OCP over SOAP over B", thus not being able to interoperate.
>
> We already see this happening in the SIP area, where some
> vendors only
> implement SIP over TCP, and others only SIP over SCTP - whether this
> is "allowed" by the standards or not...
>
> -Markus
>
>
---
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