But the ICAP client fulfills ICAP requests for all type of ICAP services,
and doesn't know the specific service requirements. As mentioned by Andre I
think having specific "service description" information describing service
requirements, options seems to be the correct approach.
-----Original Message-----
From: Yang, Lily L [mailto:lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com]
Sent: Thursday, May 31, 2001 3:18 PM
To: 'Andre Beck'; Jeremy Elson
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: iCAP Issues at OPES Workshop
I agree that this might be a good approach for more higher
level things
which are outside of any specific protocol. But things like
preview are very
ICAP specific and it is best to keep that inside of the ICAP
between the
client and server. So, yes, meta-data like what callout
protocol is used,
whether or not the header gets modified, whether or not the
content gets
modified etc., belong to OMML. If preview is a general
concept outside of
ICAP, we can consider that in OMML. But currently preview is very much
specific to ICAP and ICAP client kind of depends upon that
info to make
effective connection with the server, I strongly recommend
include that
inside ICAP. This means only ICAP client needs to know about
this, but not
the higher level component like the OPES intermediary device
and the rule
engine. It simplifies the matter.
Lily
-----Original Message-----
From: Andre Beck [mailto:abeck(_at_)bell-labs(_dot_)com]
Sent: Wednesday, May 30, 2001 2:54 PM
To: Jeremy Elson
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: iCAP Issues at OPES Workshop
Jeremy Elson wrote:
Right now we're working in advance of the midterm OPES
meeting to get
a new draft out based on feedback we've gotten, and it has some
recommendations for OPTIONS. But, I suspect that many
options will be
service-specific and defined by the application.
Another approach may be to leave these service-specific
requirements out
of scope for iCAP and use a general service description
language (e.g.
OMML) to specify service characteristics like supported callout
protocol, preferred preview size, what parts of the original
message may
get modified etc.
This would be very helpful in environments that support local
and remote
services as well as different callout protocols.
-Andre