Sukanya S writes:
I have few doubts regarding ICAP (Ref
http://www.circlemud.org/~jelson/icap-1.72.txt).
As John Martin mentioned in an earlier email, I think the main thing
to understand is that ICAP doesn't specify any kind of service
discovery. It some sense it's like HTTP: a protocol for accessing a
resource, assuming that you know from some out-of-band method the name
of the resource you want. HTTP servers generally don't advertise
lists of legal URLs; same with ICAP.
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?
In ICAP there is no way for an end-user to present authorization or
credentials to an ICAP server. We assume (for now, at least) that the
end-user presents credentials to an HTTP proxy/ICAP client (using the
normal HTTP mechanism for doing so). The HTTP proxy can then access
an ICAP server using its own credentials, or perhaps passing the same
user credentials on to the ICAP server. (Either way this assumes a
fairly tight administrative coupling between ICAP client and ICAP
server)
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.
If I'm understanding your question, I think the answer is no.
Maybe there is an analogy to SOAP here; in order to access a service
you have to know semantically what the service does beforehand. WSDL
can describe the types of arguments to your SOAP client framework, but
you (the human) need some out-of-band information beforehand to know
what the service URI you're accessing is supposed to do and the
semantics of the arguments it expects.
4) In 4.10.2 OPTIONS Response,
-- Transfer-Preview:
[should match that described at]
(Ref http://www.i-cap.org/icap/media/virus_spec.html Section
3.1.5)
Yep, I think this is a bug... we'll fix it.
-Jer