On Tue, 27 May 2003, jfcm wrote:
While in the process of trying to sell a budget for developping OCP,
I meet requests coming from different WGs I would like to note for
the records.
1. support of sub-schemes. Let say I want to access http://abc.com
in French. I would like to use the RFC 3066 code for French (fre)
and type http-fre://abc.com and have a translating OPES taking over.
This kind of adaptation is supported by OCP but is probably out of
OPES scope due to the following IAB consideration:
(4.1) URI resolution: OPES documentation must be clear in describing
these services as being applied to the result of URI resolution,
not as URI resolution itself.
That is, OPES protocols and mechanisms may work well for what you want
to do, but supporting this use case directly will not be possible in
OPES working group.
You will also have to have the OPES processor very close to, if not
embedded into, the browser because the infrastructure may not support
propagation of http-fre: URLs/requests. This is also, IMO, an inferior
design because you are overloading the meaning of the schema ("http")
into access protocol plus an OPES service. Perhaps a cleaner and more
robust solution would be to put adaptation specifics into HTTP headers
or use
http://abc.com?opes-trans=fre
or even
http://fre.opes-service.com/?url=abc.com
or something along those lines?
2. Longhorn (Windows 2005) will abandon the notion of user files and
replace them by blobs in a BillSQL database (partly as Dick Pick was
also doing). This seems of interest to OCP. I maybe wrong but this
may introduce an interesting security feature. OCP can transport
Longhorn crypted blobs to Longhorn receiver. We have an end-to-end
user security without any interface CPU load.
Possible with OCP but out of OPES scope (there seems to be no proxying
or adaptation involved). I am also not sure OCP is the best protocol
for the task because OCP is designed for adaptation, not just
forwarding. That is, it is optimized for the case where you want to
get an adapted response back from the callout server.
4. in my DNS line of thinking, the support of the PNS (private
naming space) together with the DNS could be the same way. The basic
idea of the PNS working group is to use 1 letter TLDs as the network
side of 1 letter schemes local disks. C:> means your C local disk,
http://xxx.c means in your ".c" private space. All the DNS
(protocol) calls could be trough an OPES redirecting them depending
on the alias I gave to ".c" or to "xxx.c" (some kind of dynamic
DNAME).
I guess this is similar to #1 as far as OCP support and OPES scope are
concerned.
HTH,
Alex.