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