Subject: RE: SOAP and OCP

From: jfcm <[email-masked]>
Date: Tue, 22 Apr 2003 21:07:46 +0200

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:[email-masked]>mailto:[email-masked]]
> > Sent: Tuesday, April 22, 2003 11:52 AM
> > To: [email-masked]
> > 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

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 22 Apr 2003 14:03:47 -0600 (MDT)

-- subject was "OCP and OPES"

On Tue, 22 Apr 2003, jfcm wrote:

> 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 see no architectural reason to exclude DNS from the set of adaptable
protocols a priory. However, I have to note that DNS is different
from, say, SMTP (not to mention HTTP) because it is not really "store
and forward" or "proxy" protocol. AFAIK, there is no real "final
destination" in a typical DNS query; a DNS server may be configured to
send authoritative responses (it becomes the final destination then)
or may forward the query elsewhere (it becomes a DNS "hop" then,
essentially). Thus, a DNS server doing OPES transformations may not be
a real "intermediary" as prescribed by OPES architecture. The
distinction should not cause any significant problems though, IMO.

Some OPES features such as tracing would not be fully available for
DNS/UDP exchanges due to packet size limitations, I guess. Zone
exchanges over TCP should not suffer from these limitations. The two
DNS applications (query resolution and zone transfer) have to be
considered separately because they are, essentially, separate
protocols.

> I am sure that SOAP is quite heavy/slow to support that.

Probably, at least in a typical SOAP environment.

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

If a query destination (DNS.2 server) generates a response, then this
is not an adaptation/OPES, IMO. I would adjust the above description
to better fit current OPES architecture:

	- DNS server D receives a query for iTLD
	- D, acting as an OPES processor, adapts the query
	  so that the internationalized domain is encoded
	  to avoid compatibility problems with other (old)
	  DNS servers; this step may use OCP and callout servers
	- D forwards adapted query to another DNS server
	  (possibly self)
	- D receives a reply
	- D, acting as an OPES processor, adapts the reply
	  to match internationalized encoding rules; this
	  step may use OCP and callout servers
	- D forwards adapted (iTLD) reply to the calling party

Notice how essentially the same processing is now described from the
OPES point of view, properly isolating OCP and making it optional.

Alex.