Abbie Barbir | 4 May 13:00 2003

Tracing Draft version-05042003

hi,

attached is the updated version of the tracing draft.
please provide feedback ASAP.

Note: This is work in progress. I am on the road with limited e-mail access untill May 8th.

Regards

Abbie

 


Network Working Group                                          A. Barbir
Internet-Draft                                           Nortel Networks
Expires: November 2, 2003                                    May 4, 2003

                              OPES Tracing
                       draft-ietf-opes-tracing-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 2, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This memo provides a discussion of tracing requirements for OPES as
   part of addressing the IAB considerations on this issue.

Barbir                  Expires November 2, 2003                [Page 1]

Internet-Draft               OPES Tracing                       May 2003

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Requirements for Notification in an OPES Flow  . . . . . . .  4
   2.1   Notification Concerns  . . . . . . . . . . . . . . . . . . .  5
   2.2   How to Fulfill Notifications Requirements  . . . . . . . . .  6
   3.    Requirements for Tracing in an OPES Flow . . . . . . . . . .  8
   3.1   What is traceable? . . . . . . . . . . . . . . . . . . . . .  8
   3.1.1 Requirements for Information Related to Traceable
         Entities . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.2   Tracing and Trust Domains  . . . . . . . . . . . . . . . . .  9
   3.3   Tracing and OPES System Granularity  . . . . . . . . . . . .  9
   3.4   Requirements for In-Band Tracing . . . . . . . . . . . . . . 10
   3.4.1 Tracing Information Granularity andPpersistence levels
         Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.4.2 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . 10
   3.5   Tracing Requirements and Privacy . . . . . . . . . . . . . . 10
   3.6   Requirements for OCP Support for Tracing . . . . . . . . . . 10
   3.7   How to Support Tracing . . . . . . . . . . . . . . . . . . . 11
   3.8   Tracing Examples and Scenarios . . . . . . . . . . . . . . . 12
   3.8.1 Tracing as a Callout Service . . . . . . . . . . . . . . . . 12
   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 14
         Normative References . . . . . . . . . . . . . . . . . . . . 15
         Informative References . . . . . . . . . . . . . . . . . . . 16
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
         Intellectual Property and Copyright Statements . . . . . . . 18

Barbir                  Expires November 2, 2003                [Page 2]

Internet-Draft               OPES Tracing                       May 2003

1. Introduction

   The Open Pluggable Edge Services (OPES) architecture [8] enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data consumer.

   The execution of such services is governed by a set of rules
   installed on the OPES processor.  The rules enforcement can trigger
   the execution of service applications local to the OPES processor.
   Alternatively, the OPES processor can distribute the responsibility
   of service execution by communicating and collaborating with one or
   more remote callout servers. As described in [8], an OPES processor
   communicates with and invokes services on a callout server by using a
   callout protocol.

   In [2] the IAB has required OPES solutions to address end user and
   content provider notification concerns. IAB, considerations regarding
   notification suggests that the overall OPES framework needs to assist
   content providers in detecting and responding to client-centric
   actions by OPES intermediaries that are deemed inappropriate by the
   content provider, and that the overall OPES framework should assist
   end  users in detecting the behavior of OPES intermediaries,
   potentially  allowing them to identify imperfect or compromised
   intermediaries. This document specifies tracing mechanisms that
   address those concerns. The work focus on developing tracing
   requirements that can be used to fulfil the notification and
   Non-Blocking suggestions from the IAB. The appropriate design of
   tracing mechanisms can properly address the notification requirements
   without introducing added complexity to the OPES architecture.

   In the OPES architecture document [8], there is a requirement of
   relaying tracing information in-band. This work investigates this
   possibility and discusses possible methods that could be used to
   detect faulty OPES processors or callout servers by end points in an
   OPES flow. Furthermore, the work addresses IAB consideration (3.3)
   (Non-blocking) that suggests that the OPES architecture must not
   prevent the end consumer application from accessing a non OPES
   version of the content if that version is avilable.

   The document is organized as follows: Section 2 considers ? Section
   3? etc.

Barbir                  Expires November 2, 2003                [Page 3]

Internet-Draft               OPES Tracing                       May 2003

2. Requirements for Notification in an OPES Flow

   This section examines IAB [2] considerations (3.1) and (3.2)
   regarding notification in an OPES architecture. The IAB
   considerations are reiterated here for ease of reference.

   (3.1) Notification: The overall OPES framework needs to assist
   content providers in detecting and responding to client-centric
   actions by OPES intermediaries that are deemed inappropriate by the
   content provider.

   (3.2) Notification: The overall OPES framework should assist end
   users in detecting the behavior of OPES intermediaries, potentially
   allowing them to identify imperfect or compromised intermediaries.

   Before discussing notification, it is beneficial to define what
   tracing means. Tracing is defined as the inclusion of necessary
   information within a message in an OPES flow that could be used to
   identify the set of transformations or adpatations that have been
   performed on its content before its delivery to an end point (the
   data consumer application). Tracing SHOULD be performed on per
   message basis. The format is dependent on the application level
   protocol that is used by the OPES system. The architecture requires
   that tracing be supported in-band. Furthermore, tracing can be used
   as a tool by the end user data application to infer the actions that
   has been performed by the OPES system.

   On the otherhand, notification propagates in opposite direction of
   tracing and cannot be attached to application messages that it
   notifies about. Notification can be done out-band and may require the
   development of a new protocol. The direction of data flow for tracing
   and notification are deoicted in Figure 1.

Barbir                  Expires November 2, 2003                [Page 4]

Internet-Draft               OPES Tracing                       May 2003

                                      Notification
                +-----------------------------------------------
                |                                               |
                |                                               V
          +---------------+            +-------+       +---------------+
          |               |            |       |       | Data Provider |
          | Data Consumer | Tracing    | OPES  |<----->|  Application  |
          |  Application  |<-----------|       |       +---------------+
          +---------------+            +-------+
                                           ^
                                           |OCP
                                           |
                                           V
                                       +---------+
                                       | Callout |
                                       | Server  |
                                       +---------+

                      Figure 1: Notification Flow

2.1 Notification Concerns

   Notifications for every HTTP request can burden some content
   providers. Therefore, it might be preferable to consider mechanisms
   that allow for the  explicit request of notification. Hence, a
   mechanism for explicit request of notification May be required.

   Furthermore, end point privacy is a concern. An end user may consider
   information about OPES services applied on their behalf as private.
   For example, if translation for braille device has been applied, it
   can be concluded that the user is having eyesight problems; such
   information may be misused if the user is applying for a job online.
   Similarly, a content provider may consider information about its OPES
   services private. For example, use of a specific OPES intermediary by
   a high traffic volume site may indicate business alliances that have
   not been publicly announced yet. Another example of privacy, include
   situations where a user may not want to reveal to any content
   provider all the OPES services that have been applied on their
   behalf. For example, why should every content provider know what
   exact virus scanner a user is using?

   Security is also a concern. An attacker may benefit from knowledge
   of internal OPES services layout, execution order, software versions
   and other information that are likely to be present in  automated
   notifications.

Barbir                  Expires November 2, 2003                [Page 5]

Internet-Draft               OPES Tracing                       May 2003

   The level of available details in notifications versus content
   provider interest in supporting notification is a concern.
   Experience shows that content providers often require very detailed
   information  about user actions to be interested in notifications at
   all. For example, Hit Metering protocol [11] has been designed to
   supply content providers with proxy cache hit counts, in an effort to
   reduce cache busting behavior which was caused by content providers
   desire to get accurate site "access counts". However, the Hit
   Metering protocol is currently not widely deployed. This is because
   the protocol does not supply  content providers with information such
   as client IP addresses, browser versions, or cookies.

   The Hit  Metering experience is relevant because Hit Metering
   protocol was  designed to do for HTTP caching intermediaries what
   OPES notifications are meant to do for OPES intermediaries. Thus, it
   is important to have the right balance when specifying the
   notofication requirements for OPES.

2.2 How to Fulfill Notifications Requirements

   IAB consideration (3.1) suggests that the overall OPES framework
   needs to assist content providers in detecting and responding to
   client-centric actions by OPES intermediaries that are deemed
   inappropriate by the content provider.

   It is important to note that most client-centric actions happen after
   the application message has left the content provider(s). Thus,
   notifications cannot be piggy-backed to application messages and have
   to travel in the opposite direction of traces, see Figure 1. To
   address this requirement directly, one would have to develop an out
   of band protocol to support notification.

   At this stage, there is no need to develop an out of band protocol to
   support notification, since requiring the OPES architecture to having
   a  tracing facility can fulfil the objectives of notification. In
   this regard, it is recommended that tracing MUST be always-on, just
   like HTTP Via headers. This should eliminate notification as a
   separate requirement.

   In other words, the IAB choice of "Notification" label is interpreted
   as "Notification assistance" (i.e. making notifications meaningful)
   and is not be interpreted as a "Notification protocol".  Therefore,
   the work treats IAB considerations (3.1 and 3.2) as informative (not
   normative).

   If the OPES end points cooperate then notification can be supported
   by tracing. Content providers that suspect or experience difficulties
   can do any of the following:

Barbir                  Expires November 2, 2003                [Page 6]

Internet-Draft               OPES Tracing                       May 2003

   o  Check whether requests they receive pass through OPES
      intermediaries. Presence of OPES tracing info will determine that.
      This check is only possible for request/response protocols. For
      other protocols (e.g., broadcast or push), the provider would have
      to assume that OPES intermediaries are involved until proven
      otherwise.

   o  If OPES intermediaries are suspected, request OPES traces from
      potentially affected user(s). The trace will be a part of the
      application message received by the user software. If users
      cooperate, the provider(s) have all the information they need. If
      users do not cooperate, the provider(s) cannot do much about it
      (they might be able to deny service  to uncooperative users in
      some cases).

   o  Some traces may indicate that more information is available by
      accessing certain resources on the specified OPES intermediary or
      elsewhere. Content providers may query for more information in
      that case.

   o  If everything else fails, providers can enforce no-adaptation
      policy using appropriate OPES bypass mechanisms and/or end-to-end
      mechanisms.

Barbir                  Expires November 2, 2003                [Page 7]

Internet-Draft               OPES Tracing                       May 2003

3. Requirements for Tracing in an OPES Flow

   In [2], the IAB has required that the OPES architecture provide
   tracing and debugging facilities. From [8], the OPES architecture
   SHOULD assist consumer application in detecting the behavior of OPES
   processors and callout servers to potentially allow them to identify
   imperfect or compromised operations.

   The OPES architecture document [8] has addressed these concerns at a
   higher level. The architecture requires that tracing be feasible on
   an OPES flow per OPES processor using in-band annotation. This
   requirement provides a participant with the ability to detect OPES
   intermediaries in the course of normal interaction.

3.1 What is traceable?

   Tracing should provide information to end points in an OPES flow that
   enable it to identify the various entities that are involved. The
   main focus of this work is the data consumer application end point.
   The following entities SHOULD be identified in a trace by a data
   consumer application end point:

   o  The data consumer application end point MUST be able to identify
      the OPES processors that have acted on an application message.

   o  The data consumer application end point SHOULD be able to identify
      OPES services (including callout services) that were performed on
      request/responses that are part of an application message.

   o  TBD.

   o  TBD.

3.1.1 Requirements for Information Related to Traceable Entities

   o  The privacy policy at the time it dealt with the message.

   o  Identification of the party responsible for setting and  enforcing
      that policy.

   o  Information pointing to a technical contact

   o  Information that identifies, to the technical contact, the OPES
      processors involved in processing the message

   From a architectural standpoint, every OPES processor MUST be a
   traceable entity but callout servers MAY be traceable entities.

Barbir                  Expires November 2, 2003                [Page 8]

Internet-Draft               OPES Tracing                       May 2003

3.2 Tracing and Trust Domains

   A trust domain may include several OPES systems and entities. Within
   a trust domain, there MUST be at least support for one trace entry
   per system. Entities outside of that system may or may not see any
   traces, depending on domain policies or configuration. For example,
   if an OPES system is on the content provider "side", end-users are
   not guaranteed any traces. If an OPES system is working inside
   end-user domain, the origin server is not guaranteed any traces
   related to user requests.

3.3 Tracing and OPES System Granularity

   There are two distinct uses of traces. First, is to SHOULD enable the
   "end (content producer or consumer) to detect OPES processor presence
   within end's trust domain. Such "end" should be able to see a trace
   entry, but does not need to be able to interpret it beyond
   identification of the trust domain(s).

   Second, the domain administrator SHOULD be able to take a trace entry
   (possibly supplied by an "end? as an opaque string) and interpret it.
   The administrator must be able to identify OPES processor(s) involved
   and may be able to identify applied adaptation services along with
   other message-specific information. That information SHOULD help to
   explain what OPES agent(s) were involved and what they did. It may be
   impractical to provide all the required information in all cases.
   This document view a trace record as a hint, as opposed to an
   exhaustive audit.

   Since the administrators of various trust domains can have various
   ways of looking into tracing, they MAY require the choice of freedom
   in what to put in trace records and how to format them. Trace records
   should be easy to extend beyond basic OPES requirements. Trace
   management algorithms should treat trace records as opaque data to
   the extent possible.

   It is not expected that entities in one trust domain to be able to
   get all OPES-related feedback from entities in other trust domains.
   For example, if an end-user suspects that a served is corrupted by a
   callout service, there is no guarantee that the use will be able to
   identify that service, contact its owner, or debug it _unless_ the
   service is within my trust domain. This is no different from the
   current situation where it is impossible, in general, to know the
   contact person for an application on an origin server that generates
   corrupted HTML; and even if the person is known, one should not
   expect that person to respond to end-user queries.

Barbir                  Expires November 2, 2003                [Page 9]

Internet-Draft               OPES Tracing                       May 2003

3.4 Requirements for In-Band Tracing

   The OPES architecture [8] states that traces must be in-band. The
   support of this design specification is dependent on the specifics of
   the message application level protocol that is being used in an OPES
   flow. In-band tracing limits the type of application protocols that
   OPES can support. The details of what a trace record can convey is
   also dependent on the choice of the application level protocol.

   For these reasons, the work will document requirements for
   application protocols that need to support OPES traces. However, the
   architecture does not prevent implementers of developing out-of-band
   protocols and techniques to address the above limitation.

3.4.1 Tracing Information Granularity andPpersistence levels
      Requirements

   In order to be able to trace entities that have acted on an
   application message in an OPES flow, there may be requirements to
   keep information that is related to the following:

   o  Message-related informatio: All data that describes specific
      actions performed on the message SHOULD be provided with that
      message, as there is no other way to find message level details
      later.

   o  Session related information: Session level data MUST be preserved
      for the duration of the session. OPES processor is responsible for
      inserting notifications if session-level information changes.

   o  End-point related data: What profile is activated? Where to get
      profile details? Where to set preferences?

   o  TBD

3.4.2 Protocol Binding

   How tracing is added is application protocol-specific and will be
   documented in separate drafts. This work documents what tracing
   information is required and some common tracing elements.

3.5 Tracing Requirements and Privacy

3.6 Requirements for OCP Support for Tracing

   If it is the task of an OPES processor to add trace records to

Barbir                  Expires November 2, 2003               [Page 10]

Internet-Draft               OPES Tracing                       May 2003

   application messages, then the OCP protocol is not affected by
   tracing requirements. In order for an OCP protocol to be tracing
   neutral, the OPES server SHOULD be able to meet the following
   requirements:

   o  Callout services adapt payload regardless of the application
      protocol in use and leave header adjustment to OPES processor.

   o  OPES processor SHOULD able  to trace its own invocation and
      service(s) execution because OPES processor understand the
      application protocol.

   o  Callout servers  MAY be able to add their own OPES trace records
      to application level messages.

   o

3.7 How to Support Tracing

   In order to support tracing, the following aspects must be addressed:

   o  There MUST be a System Identifier that identify a domain that is
      employing an OPES system.

   o  An OPES processor MUST be able to be uniquely identified (MUST
      have an Identifier) within a system.

   o  An OPES processor MUST add its identification  to the trace.

   o  An OPES processor SHOULD add to the trace  identification of every
      callout service that received the application message.

   o  An OPES processor MUST add to the trace identification  of the
      "system/entity" it belongs to. "System" ID MUST make it possible
      to access "system" privacy  policy.

   o  An OPES processor MAY group the above information for sequential
      trace entries having  the same "system/entity" ID. In other words,
      trace  entries produced within the same "system/entity"  MAY be
      merged/aggregated into a single less detailed trace entry.

   o  An OPES processor MAY delegate trace management to  a callout
      service within the same "system/entity".

Barbir                  Expires November 2, 2003               [Page 11]

Internet-Draft               OPES Tracing                       May 2003

3.8 Tracing Examples and Scenarios

   TBD

3.8.1 Tracing as a Callout Service

   TBD

Barbir                  Expires November 2, 2003               [Page 12]

Internet-Draft               OPES Tracing                       May 2003

4. Security Considerations

Barbir                  Expires November 2, 2003               [Page 13]

Internet-Draft               OPES Tracing                       May 2003

5. IANA Considerations

   The proposed work will evaluate current protocols for OCP. If the
   work determines that a new protocol need to be developed, then there
   may be a need to request new numbers from IANA.

Barbir                  Expires November 2, 2003               [Page 14]

Internet-Draft               OPES Tracing                       May 2003

Normative References

   [1]  McHenry, S., et. al, "OPES Scenarios and Use Cases",
        Internet-Draft TBD, May 2002.

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [4]  OPES working group, "OPES Service Authorization and Enforcement
        Requirements", Internet-Draft TBD, May 2002.

   [5]  OPES working group, "OPES Ruleset Schema", Internet-Draft TBD,
        May 2002.

   [6]  A. Beck et al., "Requirements for OPES Callout Protocols",
        Internet-Draft http://www.ietf.org/internet-drafts/
        draft-ietf-opes-protocol-reqs-03.txt, December 2002.

   [7]  A. Barbir et al., "Security Threats and Risks for Open Pluggable
        Edge Services", Internet-Draft http://www.ietf.org/
        internet-drafts/draft-ietf-opes-threats-00.txt, October  2002.

   [8]  A. Barbir et al., "An Architecture for Open Pluggable Edge
        Services (OPES)", Internet-Draft http://www.ietf.org/
        internet-drafts/draft-ietf-opes-architecture-04, December  2002.

Barbir                  Expires November 2, 2003               [Page 15]

Internet-Draft               OPES Tracing                       May 2003

Informative References

   [9]   Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
         Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
         Waldbusser, "Terminology for Policy-Based Management", RFC
         3198, November 2001.

   [10]  L. Cranor,  et. al, "The Platform for Privacy Preferences 1.0
         (P3P1.0) Specification", W3C Recommendation 16 http://
         www.w3.org/TR/2002/REC-P3P-20020416/ , April  2002.

   [11]  "Hit Metering", RFC .

Author's Address

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb <at> nortelnetworks.com

Barbir                  Expires November 2, 2003               [Page 16]

Internet-Draft               OPES Tracing                       May 2003

Appendix A. Acknowledgements

   This document is the product of OPES WG. Oskar Batuner (Independent
   consultant) and Andre Beck (Lucent) are additional authors that have
   contributed to this current document.

   Earlier versions of this work was done by Gary Tomlinson (The
   Tomlinson Group) and Michael Condry (Intel).

   The authors gratefully acknowledge the contributions of: John Morris,
   Mark Baker, Ian Cooper and Marshall T. Rose.

Barbir                  Expires November 2, 2003               [Page 17]

Internet-Draft               OPES Tracing                       May 2003

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Barbir                  Expires November 2, 2003               [Page 18]

Internet-Draft               OPES Tracing                       May 2003

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Barbir                  Expires November 2, 2003               [Page 19]


Martin Stecher | 5 May 12:24 2003

RE: OCP transport nomination


It got quite on this.

Does this mean that everybody feels just fine with BEEP?
No other nominations?
No OCPTRAN?
No more arguments?

Although BEEP seems to be a very good candidate to build OCP on,
I am still not convinced that it is the best choice.
I have little to no technical argumentation for this; it is more
personal gusto and ICAP support.

If we compare the work that needs to be done to adjust BEEP for OCP
plus the XML burdon that every implementor has to take with the
work that we'd need to do to define another transport protocol, is
there a huge difference?

As you know, I would like to see something that could be called
ICAP/2.0.
So maybe something that takes all the good elements of BEEP but
looks different, for example establishing a channel could look
like this:

	C:OPEN icap://my-OPES-service.org/translate ICAP/2.0
	C:Channel: 1
	C:
	S:ICAP/2.0 200 Channel Established
	S:Channel: 1
	S:
	
Regards
Martin

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov <at> measurement-factory.com]
> Sent: Thursday, April 24, 2003 5:41 PM
> To: ietf-openproxy <at> imc.org
> Subject: OCP transport nomination
> 
> 
> 
> 
> I would like to nominate BEEP as the only OCP transport. My primary
> reasons for nominating BEEP are:
> 
> 	- reuse of BEEP negotiation capabilities for
> 	  transport encryption and such
> 
> 	- availability of efficient transfer for
> 	  opaque ("binary") data
> 
> There are several issues that we would need to resolve if BEEP is
> selected by the group (e.g., selecting BEEP message exchange model and
> defining OCP message encoding), but I would like to hear other
> protocol nominations (Hilarie?) or any objections to BEEP before
> discussing BEEP-specific details.
> 
> I hope I am not making a mistake by giving BEEP a preference over
> SOAP. I would really like to use SOAP because that is what web
> services world is using, and we are doing something very similar.
> 
> Unfortunately, SOAP suffers from a legacy of being started as an RPC
> protocol and has no standard way of handling large opaque data
> [efficiently]. If BEEP is selected, we would essentially trade
> "efficient transfer" for "current deployment". I hope that is the
> right choice, especially since SOAP can still be used as another
> callout protocol in environments where efficient transfer is not
> important. If you think otherwise, please speak up now.
> 
> 
> We have talked about all known transport candidates except Hilarie's
> OCPTRAN.  Let's move this discussion to a closure. OCP work cannot
> proceed much further without the transport selection.
> 
> Thank you,
> 
> Alex.
> 

Alex Rousskov | 5 May 18:36 2003

RE: OCP transport nomination


On Mon, 5 May 2003, Martin Stecher wrote:

> It got quite on this.
> Does this mean that everybody feels just fine with BEEP?
> No other nominations?
> No OCPTRAN?
> No more arguments?

Personally, I am waiting for feedback from others. Hilarie mentioned
OCPTRAN once, but has not provided any details/arguments since. I do
not want to spend time detailing OCPTRAN if nobody backs it. If
Hilarie argues for OCPTRAN and/or this discussion drives you towards
OCPTRAN, then there will be somebody backing it...

> Although BEEP seems to be a very good candidate to build OCP on, I
> am still not convinced that it is the best choice. I have little to
> no technical argumentation for this; it is more personal gusto and
> ICAP support.
>
> If we compare the work that needs to be done to adjust BEEP for OCP
> plus the XML burdon that every implementor has to take with the work
> that we'd need to do to define another transport protocol, is there
> a huge difference?

If two "average" OCP implementors start from scratch, I do not expect
a huge difference in implementation effort of OCP/BEEP versus
OCP/OCPTRAN. BEEP implementations will benefit from the existing code
and expertise, even if they do not use that code directly. OCPTRAN
implementors will benefit from a simpler, domain-specific protocol and
may benefit from existing ICAP code/expertise if OCPTRAN is similar to
ICAP.

I think a big difference is in supporting things like transport
encryption (e.g., TLS) and similar add-ons that BEEP gives us, the
protocol writers, for "free". It would take us a while to document
those things in OCPTRAN (or we would have to leave them unspecified
for the first version of the protocol). It would take implementors a
while to implement them without having much experience/code out there.

> As you know, I would like to see something that could be called
> ICAP/2.0.

Political issues aside, I think it is possible to call OCP "ICAP/2.0"
regardless of the transport protocol choice. We are doing the same
conceptual thing ICAP does. Transport is just a low-level detail.

> So maybe something that takes all the good elements of BEEP but
> looks different, for example establishing a channel could look like
> this:
>
> 	C:OPEN icap://my-OPES-service.org/translate ICAP/2.0
> 	C:Channel: 1
> 	C:
> 	S:ICAP/2.0 200 Channel Established
> 	S:Channel: 1
> 	S:

Possible, if we are OK with losing existing BEEP support for session
encryption.

Also, one good thing about BEEP messages is that they all have a
known, easily-available size (encoded as an integer value in the first
line of a message). The above looks similar to HTTP and loses the
known-size advantage. The size can be added as a "Content-Length"
header, of course, but you have to parse a lot more to get to that.
Alternatively, we can add size to the first line and lose similarity
with ICAP/HTTP.

I think what we need to understand is whether you do not want BEEP
just because it uses XML or because it does not look like ICAP/HTTP.
Once we know the true obstacle, we can try to see how BEEP can be
modified to remove that obstacle.

For example, it is probably possible to define OCPTRAN as "XML-less"
BEEP while providing a simple BEEP-to-OCPTRAN conversion and, hence,
reusing (redefining without much effort) most of the existing BEEP
work. This approach would be similar to, say, binary XML that exist
for wireless protocols (binary XML gets virtually all the advantages
of XML but uses different representation for various performance
reasons).

Similarly, we can "convert" BEEP to HTTP-like BEEP.

Comments?

Alex.

Picon

RE: OCP transport nomination


I'm trying to work my way through the issues here.  

Where is the definition of the TLS profile for BEEP?

There have been alllusions to XML licensing issues.  What are they?

Hilarie

Alex Rousskov | 5 May 21:47 2003

RE: OCP transport nomination


On Mon, 5 May 2003, The Purple Streak, Hilarie Orman wrote:

> Where is the definition of the TLS profile for BEEP?

See RFC 3080 (Sections 3.1 and 7.2, at least):

	<profile uri="http://xml.resource.org/profiles/TLS">
	   <ready />
	</profile>

> There have been alllusions to XML licensing issues.  What are they?

I am not aware of any; can you be more specific? If BEEP (an IETF
protocol) uses XML, we should be safe to do so, I guess.

Alex.

Picon

RE: OCP transport nomination


Please show me how to use the URI to find the document.  I can use it to
find "404", but then, lots of things can find "404".

>  On Mon, 5 May 2003, The Purple Streak, Hilarie Orman wrote:
>  > Where is the definition of the TLS profile for BEEP?
>  See RFC 3080 (Sections 3.1 and 7.2, at least):
>	   <profile uri="http://xml.resource.org/profiles/TLS">
>	      <ready />
>	   </profile>

In this message you referred to "the MIT license"; what did you mean?

  From: Alex Rousskov <rousskov <at> measurement-factory.com>
  To: ietf-openproxy <at> imc.org
  Subject: Re: BEEP as OCP transport
  Date: Thu, 17 Apr 2003 12:22:09 -0600 (MDT)
  In-Reply-To: <20030417102820.064ae9ed.mrose <at> dbc.mtview.ca.us>
  Message-ID: <Pine.BSF.4.53.0304171132590.31225 <at> measurement-factory.com>

>  > There have been alllusions to XML licensing issues.  What are they?

>  I am not aware of any; can you be more specific? If BEEP (an IETF
>  protocol) uses XML, we should be safe to do so, I guess.

Marshall Rose | 5 May 22:40 2003
Picon
Picon

Re: OCP transport nomination


[ speaking as beep guy ... ]

> Please show me how to use the URI to find the document.  I can use it to
> find "404", but then, lots of things can find "404".
> >
> >	   <profile uri="http://xml.resource.org/profiles/TLS">
> > ...

there is a school of thought that URIs can be used to uniquely-identify things,
and that those things don't necessarily have to be available via the web.

if you read 3080, it will tell you what to do when someone tries to start a
profile with the above-mentioned URI.

> In this message you referred to "the MIT license"; what did you mean?

a lot of open source stuff is published under an "the MIT license". although
i'm sure that lots of folks claim intellectual property rights with
respect to doing nifty things with xml, the actual 1.0 specification
itself, as far as anyone reasonably knows, is unencumbered.

/mtr

Martin Stecher | 5 May 22:38 2003

AW: OCP transport nomination


Alex,

> [...]
> 
> Also, one good thing about BEEP messages is that they all have a
> known, easily-available size (encoded as an integer value in the first
> line of a message). The above looks similar to HTTP and loses the
> known-size advantage. The size can be added as a "Content-Length"
> header, of course, but you have to parse a lot more to get to that.
> Alternatively, we can add size to the first line and lose similarity
> with ICAP/HTTP.

I also like the size information.
But BEEP is only a little ahead to today's ICAP/1.0.
The size is for the payload only, you still need to parse frame
header and footer. In ICAP/1.0 there is the chunked transfer encoding
which is a little less but mainly the same.
I think that OCP should extend the usage of size information, if
possible even for OCP meta data.

> 
> I think what we need to understand is whether you do not want BEEP
> just because it uses XML or because it does not look like ICAP/HTTP.
> Once we know the true obstacle, we can try to see how BEEP can be
> modified to remove that obstacle.

It's something of both.
First, I assume that a complete OCP on BEEP protocol specification
would define many XML fields like the greeting message as fixed or as
only a small set of possible values.
Only little information could really benifit from XML flexibility.
But a full compatible implementation will nevertheless need a
full featured XML parser as you pointed out earlier.
That looks like a lot of ovehead to me.
I would rather like to get the protocol XML free.

Second, as I wrote before I like to see some migration path for
existing ICAP developers. At least a few syntax elements where we
can say "yes, that looks like a next generation of ICAP".
That's why I proposed to make the session/channel management ICAP
or HTTP like. All other messages could then look much more like
original BEEP messages

> 
> For example, it is probably possible to define OCPTRAN as "XML-less"
> BEEP while providing a simple BEEP-to-OCPTRAN conversion and, hence,
> reusing (redefining without much effort) most of the existing BEEP
> work. This approach would be similar to, say, binary XML that exist
> for wireless protocols (binary XML gets virtually all the advantages
> of XML but uses different representation for various performance
> reasons).

That's basically what I mean. Learning all the good things from BEEP
and reusing as much as possible for OCPTRAN.

Martin

Marshall Rose | 5 May 23:24 2003
Picon
Picon

Re: AW: OCP transport nomination


[ speaking as the beep guy...]

> > For example, it is probably possible to define OCPTRAN as "XML-less"
> > BEEP while providing a simple BEEP-to-OCPTRAN conversion and, hence,
> > reusing (redefining without much effort) most of the existing BEEP
> > work. This approach would be similar to, say, binary XML that exist
> > for wireless protocols (binary XML gets virtually all the advantages
> > of XML but uses different representation for various performance
> > reasons).
> 
> That's basically what I mean. Learning all the good things from BEEP
> and reusing as much as possible for OCPTRAN.

unfortunately, you've taken exactly the wrong lesson here.

if you're trying to do beep-like things, you should use beep. because,
frankly, this group isn't going to be able to make better decision
decisions than the group that did beep. quite the reverse.

obviously, if there are parts of beep that you don't like, then:

    - if they're optional, then don't use them.

    - if they're not optional, then you're not trying to do beep-like things.

and if the answer is the latter, then go off in another direction, and
that's just fine.

if your concern with beep boils down to the xml, then don't use xml in
the channel definition for ocp... use something else.  (yes, you'll
still have to use xml for beep's channel management, but that's very
constrained, and i guarantee you that you have much harder problems to
deal with than trying to optimize channel management in beep.

/mtr

Picon

Re: OCP transport nomination


OK, then there's no specification of the user-BEEP API for using TLS.
What support do the implementations of BEEP provide?  How are the
cryptographic preferences for each TLS connection specified?  My point
being that it would seem pretty easy for an OCPTRAN API implementor to
set up things in such a way that the user was responsible for opening
the correct kind of TLS connection and then passing the handle to it
to OCPTRAN.

Hilarie

>  [ speaking as beep guy ... ]

>  > Please show me how to use the URI to find the document.  I can use it to
>  > find "404", but then, lots of things can find "404".
>  > >
>  > >	   <profile uri="http://xml.resource.org/profiles/TLS">
>  > > ...

>  there is a school of thought that URIs can be used to uniquely-identify things,
>  and that those things don't necessarily have to be available via the web.

>  if you read 3080, it will tell you what to do when someone tries to start a
>  profile with the above-mentioned URI.


Gmane