ietf-openproxy
[Top] [All Lists]

Re: OPES and iCAP

2001-07-10 06:12:10
Hi all,

I have few doubts regarding ICAP (Ref
http://www.circlemud.org/~jelson/icap-1.72.txt).

1) How does the iCAP server register its service?
   How will the client come to know about the various iCAP servers available
and
   the services available in a particular server?
   Using OPTIONS the client comes to know only about the METHODS and
   configuration settings of a particular service that the client is
   enquiring about.

2) In sec 4.2
   in the syntax for iCAP URI
    authority = [ userinfo @] <host> [ ":" <port>]
   Does this userinfo indicates that of a ICAP client or the end user?
   Where does the userinfo get authenticated?

3) Does Service ID in OPTIONS msg has any syntax/semantics?
   Say there are two ICAP servers s1 and s2 both provides virus checking
   service say Norton and the advertise their service id as follows.

   s1 : Service-Id : Norton_viruscheck
   s2 : Service-Id : Norton_virus_check.

   Both use the same software/technology for virus checking and they are
   advertised with different Service Ids. How does the client knows they
   are actually the same.

4) In 4.10.2 OPTIONS Response,
   -- Transfer-Preview:

      A list of file extensions that should be sent in their entirety
      (without preview) to the ICAP server.  This header MAY be
      included in the OPTIONS response. ......

   Should it not be like

   The "Transfer-Preview" header specifies a set of file name extensions
   indicating content that MUST be previewed.
   (Ref http://www.i-cap.org/icap/media/virus_spec.html  Section 3.1.5)

Would any of you please clarify the above mentioned doubts and let us know
your comments

Thanks,
Sukanya.

Martin Stecher wrote:

I got a very positive impression of the work in OPES when I joined the
interium meeting in Santa Clara. There was a high interest in iCAP and
very good technical ideas and feedback.

--------
Side note:
On the ECMA meeting last week we had a long discussion how to get
everybody who is interested into the same boat to develop a single iCAP
standard. Since there are people that feel not comfortable with a
technical iCAP leadership of an ECMA group and others not feeling
comfortable with everything to be done by OPES, we tried to find a third
way that can work as a compromise. I hope to see the letter that was
written on the last day soon in this mailing list that will propose all
the technical work to be done within the iCAP forum (with its 120
members that are claiming to be interested in iCAP) and have strong
liaisons to OPES/IETF and ECMA to go for a RFC and an ISO norm.
--------

The more I read in this mailing list the more I am disappointed what
OPES will do with iCAP. It seems to me that it more and more disappears
from the charter and from your minds.
The sentence: "It may decide to extend or even not use the iCAP protocol
without being obliged to retain any level of compatibility with the
current iCAP proposal." is just great.
Tell me: Why should a company that wants to make business with iCAP
wants that OPES is the group that is responsable for the iCAP
development? With this charter I am afraid that this "iCAP leader" will
just stop the development and any time or will change the complete
concept of the protocol from one day to the other. Now it is this group
that just creates the danger to end up with multiple wanna-be-standards,
a matter you all were most concerned about on the workshop!

You know from my messages to this group that I do not think either that
the current iCAP version is the best protocol on earth but it works
quite well and has really a big chance in the market!!! And the current
draft (btw it's at http://www.circlemud.org/~jelson/icap-1.72.txt and
not longer draft-elson-opes-icap-01.txt as in the charter) is at least
good enough that people have a chance to write applications that work
together.

Don't misunderstand me: It's great if people are doing the research for
long-term solutions and will create an even better callout-protocol for
the future. I will carefully follow these developments and try to help
where I can but my company cannot yet effort a large research group that
just cares about the great future. We are thankful that iCAP exists
TODAY and works.

For the last couple of months, this mailing list was the discussion
forum for iCAP. I am somehow disappointed that 90% of the discussion was
only political and only a few messages dealed with the technology.
That's why I propose to create a mailing list within the iCAP forum and
to continue discussion about the real iCAP work there.

I still hope that OPES will commit to iCAP at least as a first possible
callout protocol that deserves to get standardized and will help to do
this within IETF. Then go and develop the better next protocol or
version of the protocol.

Martin Stecher
<Prev in Thread] Current Thread [Next in Thread>