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