Hi,
I think most of these questions arise from a very basic mis-conception
about iCAP: that it provides some sort of service negotiation function. It
doesn't. All it does is provide a transport protocol for services which
require vectoring of content from point to point.
At 06:43 PM 10/07/01 +0530, Sukanya S wrote:
1) How does the iCAP server register its service?
It doesn't. iCAP provides only for the transport for getting an object from
A to B. It is a simple vectoring protocol and knows nothing about the
higher-level services it is used to provide. The registration and
negotiation of services is done out of band.
How will the client come to know about the various iCAP servers
available and
the services available in a particular server?
See above. That is between either the client and the icap-client with which
they are communicating or the origin-server (content provider) and their
icap-enabled surrogate. How icap-servers are "registered" with an
icap-client is beyond the scope of the underlying transport protocol.
Using OPTIONS the client comes to know only about the METHODS and
configuration settings of a particular service that the client is
enquiring about.
Yes. What's the problem?
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?
I believe this is covered in the Security section. Only the icap-client
authenticates with the icap-server. The end-user authentication is to the
icap-client. An icap-enabled surrogate is, by definition, under the
administrative control of the content provider.
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.
The client doesn't. ...and I'm not sure I understand the problem? If I am
vectoring content to a service then I must know what that service is. If I
don't then I probably shouldn't vector content to it.
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>http://www.i-cap.org/icap/media/virus_spec.html
Section 3.1.5)
You may be right but I think SHOULD is correct here since the icap-client
may choose to send previews or not. I'll let one of the others correct me.
Rgds,
John
---------------------------------------------------------------
Network Appliance Direct / Voicemail: +31 23 567 9615
Scorpius 2 Fax: +31 23 567 9699
NL-2132 LR Hoofddorp Main Office: +31 23 567 9600
---------------------------------------------------------------