ietf-openproxy
[Top] [All Lists]

OPES Scenarios

2002-10-18 03:27:03

Hi,

I have a comment on OPES Scenarios. I would add in section 2.1.2 the following 
point:

- Access functions for the data provider, such as service authentication for 
access control.

Best regards,
Crescenzo Coppola
System Specialist
Tilab S.p.A.
V. G. Reiss Romoli, 274
10148 Torino - Italy

-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Friday, October 18, 2002 5:37 AM
To: OPES Group
Subject: Summary of ICAP discussion



Hi,

going over the emails that have recently been posted as comments on 
the latest ICAP specification (draft-elson-icap-01.txt), the issues 
raised can be summarized as follows:

(1) The latest ICAP specification as described in Internet Draft
     draft-elson-icap-01.txt is clear and helps in building
     interoperable servers/clients implementations.

(2) Implementation experience shows that ICAP is a relative light
     weight protocol, both in terms of protocol overhead and code
     complexity.

(3) The PREVIEW feature specified in ICAP is considered useful and
     important for real life deployment.

(4) It would be useful to add a standardized mechanism in ICAP that
     allows to convey additional metadata (e.g. client and subscriber
     information), maybe along the lines of the now expired draft on
     "Transmitting Subscriber Identification in iCAP"
     (draft-beck-opes-icap-subid-00.txt). In particular, a mechanism
     for transmitting subscriber information is essential for certain
     services.

(5) Minimum support for security may be provided in ICAP by just
     supporting an additional header similar to WWW-authenticate.

(6) ICAP is specifically designed for HTTP, but attempts have been
     made to encapsulate FTP and even SMTP into ICAP.

(7) The ICAP draft should mention that a single client
     request-response flow could include both reqmod and
     respmod modifications.

(8) It might be helpful to explicitely mention in the draft that ICAP
     clients should be written to check for an ICAP server's response
     while the ICAP client is sending out an encapsulated body.
     Although not directly a protocol issue, this is important to
     speed-up scenarios in which the server can provide a final
     response before receiving the entire message.

Let me further add

(8) the curent ICAP specification doesn't include a mechanism for
     tracing/notification.

(A more detailed discussion of ICAP with respect to the OPES protocol 
requirements can be found in draft-stecher-opes-icap-eval-00.txt)

In the OPES context, does anybody have any more comments on the 
existing ICAP specification. Does anyone have any comments/feelings on 
the above points, or can they be considered a collective view of this 
WG on the existing ICAP specification? In particular:

With respect to point (1), it would be interesting to learn about 
existing implementations that implement the latest ICAP spec and whose 
interoperability has already been tested (well, at least to some extend).

With respect to point (4), would it be helpful to either integrate the 
  mechanim proposed in the expired ID 
draft-beck-opes-icap-subid-00.txt into the ICAP spec, or to publish 
this mechanism in a separate compagnon document? Is this mechanism 
supported in any existing ICAP implementation? If not, how do existing 
ICAP implementations convey subscriber information to services that 
require such information?

With respect to point (5), would it be worthwhile to further explore 
this issue and maybe come up with a proposal for such addition? Or 
would it be better to leave it alone and to refer to Section 7 of the 
ICAP draft, which states the security limitations of the current spec.

With respect to point (6) - Is there a need for a more flexible 
callout protocol that can encapsulate different protocols as well 
(e.g. FTP, SMTP, or maybe even SIP)? Be careful, though - the current 
OPES charter is limited to HTTP (and RTP/RTSP)!!!

Considering the collection of comments, one might state that the 
current draft is pretty stable and describes existing and implemented 
practice, although it has some limitations with respect to the OPES 
architecture and OPES protocl requirements.

Cheers,
   Markus



====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to MailAdmin(_at_)tilab(_dot_)com(_dot_) Thank you
====================================================================

<Prev in Thread] Current Thread [Next in Thread>
  • OPES Scenarios, Coppola Crescenzo <=