Tracing Draft version-05042003

From owner-ietf-openproxy@mail.imc.org Sun May 4 07:14:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28518 for ; Sun, 4 May 2003 07:14:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CHTP-0000cv-00 for opes-archive@ietf.org; Sun, 04 May 2003 07:16:03 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19CHSy-0000cm-00 for opes-archive@ietf.org; Sun, 04 May 2003 07:15:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h44B13i2000598 for ; Sun, 4 May 2003 04:01:03 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h44B13gI000597 for ietf-openproxy-bks; Sun, 4 May 2003 04:01:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h44B12i2000562 for ; Sun, 4 May 2003 04:01:02 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h44B0lr23282; Sun, 4 May 2003 07:00:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 4 May 2003 07:00:47 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754035FD1AA@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'Alex Rousskov'" , ietf-openproxy@imc.org Cc: "Abbie Barbir" Subject: Tracing Draft version-05042003 Date: Sun, 4 May 2003 07:00:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3122B.E0E446BA" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3122B.E0E446BA Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3122B.E0E446BA" ------_=_NextPart_001_01C3122B.E0E446BA Content-Type: text/plain 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 ------_=_NextPart_001_01C3122B.E0E446BA Content-Type: text/html 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

------_=_NextPart_001_01C3122B.E0E446BA-- ------_=_NextPart_000_01C3122B.E0E446BA Content-Type: application/octet-stream; name="draft-ietf-opes-tracing-00-may4-2003.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-tracing-00-may4-2003.htm" Content-Transfer-Encoding: quoted-printable =0A= OPES Tracing=0A= =0A= =0A= =0A=
TOC
=0A=
=0A= =0A= =0A= =0A=
Network Working Group A. Barbir
Internet-Draft Nortel Networks
Expires: November 2, 2003 May 4, 2003
=0A=

OPES = Tracing

=0A=

draft-ietf-opes-tracing-00

=0A= =0A= =0A=

Status of this Memo

=0A=

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

=0A=

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

=0A=

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

=0A=

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

=0A=

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

=0A=

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

=0A= =0A=

Copyright Notice

=0A=

=0A= =0A=

Abstract

=0A= =0A=

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

=0A=

TOC

=0A=

1. =0A= Introduction

2. =0A= Requirements for Notification in an OPES Flow

2.1 =0A= Notification Concerns

2.2 =0A= How to Fulfill Notifications Requirements

3. =0A= Requirements for Tracing in an OPES Flow

3.1 =0A= What is traceable?

3.1.1 =0A= Requirements for Information Related to Traceable Entities

3.2 =0A= Tracing and Trust Domains

3.3 =0A= Tracing and OPES System Granularity

3.4 =0A= Requirements for In-Band Tracing

3.4.1 =0A= Tracing Information Granularity andPpersistence levels = Requirements

3.4.2 =0A= Protocol Binding

3.5 =0A= Tracing Requirements and Privacy

3.6 =0A= Requirements for OCP Support for Tracing

3.7 =0A= How to Support Tracing

3.8 =0A= Tracing Examples and Scenarios

3.8.1 =0A= Tracing as a Callout Service

4. =0A= Security Considerations

5. =0A= IANA Considerations

§ =0A= Normative References

§ =0A= Informative References

§ =0A= Author's Address

A. =0A= Acknowledgements

§ =0A= Intellectual Property and Copyright Statements

=0A=
=0A= =0A=

=0A=

TOC

=0A=

1. Introduction

=0A= =0A=

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.=0A= =0A=

=0A=

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. =0A= =0A=

=0A=

In [2] the IAB has required OPES solutions to = address end user and=0A= 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=0A= 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.=0A=

=0A=

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. =0A= =0A=

=0A=

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

=0A=

TOC

=0A=

2. Requirements for Notification = in an OPES Flow

=0A= =0A=

=0A=

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.=0A= =0A=

=0A=

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

=0A=

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

=0A=

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. =0A= =0A=

=0A=

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 Notification Flow .=0A= =0A= =0A=

=0A= =0A=

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

=0A=

Notification Flow =

=0A= =0A=

2.1 Notification Concerns

=0A= =0A=

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. =0A= =0A=

=0A=

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?=0A= =0A=

=0A=

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

=0A=

The level of available details in notifications versus content = provider interest in supporting notification is a concern. = Experience=0A= shows that content providers often require very detailed = information about user actions to be interested in notifications at = all. For=0A= 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.=0A= =0A= =0A=

=0A=

=0A= 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.=0A= =0A= =0A=

=0A=

2.2 How to Fulfill Notifications = Requirements

=0A= =0A=

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.=0A= =0A=

=0A=

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 Notification Flow . To address this = requirement directly, one would have to develop an out of band protocol = to support notification. =0A= =0A= =0A=

=0A=

=0A= 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.=0A= =0A=

=0A=

=0A= 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).=0A= =0A= =0A= =0A=

=0A=

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:=0A= =0A=

Check whether requests they receive pass through OPES = intermediaries. Presence of OPES tracing info=0A= will determine that. This check is only possible for = request/response protocols. For other protocols (e.g.,=0A= broadcast or push), the provider would have to assume that OPES = intermediaries are involved until proven=0A= otherwise.=0A= =0A= =0A=
If OPES intermediaries are suspected, request OPES traces from = potentially affected user(s).=0A= The trace will be a part of the application message received by the = user software. If users cooperate,=0A= the provider(s) have all the information they need. If users do not = cooperate, the provider(s) cannot=0A= do much about it (they might be able to deny service to = uncooperative users in some cases).=0A= =0A= =0A=
Some traces may indicate that more information is available by = accessing certain resources on the=0A= specified OPES intermediary or elsewhere. Content providers may = query for more information in that=0A= case.=0A= =0A= =0A=
If everything else fails, providers can enforce no-adaptation = policy using appropriate OPES=0A= bypass mechanisms and/or end-to-end mechanisms.=0A= =0A= =0A=

=0A=

TOC

=0A=

3. Requirements for Tracing in = an OPES Flow

=0A= =0A=

In [2], the IAB has required that the OPES = architecture provide tracing and debugging facilities. From =0A= [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. =0A= =0A=

=0A=

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. =0A= =0A=

=0A=

3.1 What is traceable?

=0A= =0A=

=0A= 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:=0A= =0A=

The data consumer application end point MUST be able to identify = the OPES processors that have acted on an=0A= application message.=0A= =0A=
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.=0A= =0A= =0A=
TBD.=0A= =0A=
TBD.=0A= =0A=

=0A=

3.1.1 Requirements for Information Related to = Traceable Entities

=0A= =0A=

=0A=

The privacy policy at the time it dealt with the message.=0A= =0A=
Identification of the party responsible for setting and enforcing = that policy.=0A= =0A=
Information pointing to a technical contact=0A= =0A=
Information that identifies, to the technical contact, the OPES = processors involved in processing the message =0A= =0A=

=0A=

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

=0A=

3.2 Tracing and Trust Domains

=0A= =0A=

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.=0A= =0A=

=0A=

3.3 Tracing and OPES System = Granularity

=0A= =0A=

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). =0A= =0A=

=0A=

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.=0A= =0A=

=0A=

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.=0A= =0A=

=0A=

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.=0A= =0A=

=0A=

3.4 Requirements for In-Band Tracing

=0A= =0A=

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.=0A= =0A=

=0A=

=0A= 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. =0A= =0A= =0A=

=0A=

3.4.1 Tracing Information Granularity = andPpersistence levels Requirements

=0A= =0A=

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:=0A= =0A=

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.=0A= =0A=
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. =0A= =0A=
End-point related data: What profile is activated? Where to get = profile details? Where to set preferences?=0A= =0A=
TBD=0A= =0A=

=0A=

3.4.2 Protocol Binding

=0A= =0A=

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.=0A= =0A=

=0A=

3.5 Tracing Requirements and Privacy

=0A= =0A=

=0A=

3.6 Requirements for OCP Support for = Tracing

=0A= =0A=

=0A= If it is the task of an OPES processor to add trace records to = application messages, then the OCP protocol is not affected by tracing = requirements.=0A= In order for an OCP protocol to be tracing neutral, the OPES server = SHOULD be able to meet the following requirements:=0A= =0A=

Callout services adapt payload regardless of the application = protocol in use and leave header adjustment to OPES processor. =0A= =0A=
OPES processor SHOULD able to trace its own invocation and = service(s) execution because OPES processor understand the application = protocol. =0A=
Callout servers MAY be able to add their own OPES trace records to = application level messages.=0A= =0A=
=0A=

=0A=

3.7 How to Support Tracing

=0A= =0A=

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

There MUST be a System Identifier that identify a domain that is = employing an OPES system.=0A= =0A=
An OPES processor MUST be able to be uniquely identified (MUST have = an Identifier) within a system.=0A= =0A=
An OPES processor MUST add its identification to the trace.=0A= =0A=
An OPES processor SHOULD add to the trace identification of every = callout service that received the application message.=0A= =0A= =0A=
An OPES processor MUST add to the trace identification of the = "system/entity" it belongs to. "System"=0A= ID MUST make it possible to access "system" privacy policy.=0A= =0A= =0A=
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.=0A= =0A=
An OPES processor MAY delegate trace management to a callout = service within the same "system/entity".=0A= =0A=

=0A=

3.8 Tracing Examples and Scenarios

=0A= =0A=

TBD=0A= =0A=

=0A=

3.8.1 Tracing as a Callout Service

=0A= =0A=

TBD=0A= =0A=

=0A=

TOC

=0A=

4. Security = Considerations

=0A= =0A=

=0A=

TOC

=0A=

5. IANA Considerations

=0A= =0A=

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.=0A= =0A= =0A=

=0A=

TOC

=0A=

Normative References

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

[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.

=0A= =0A=

=0A=

TOC

=0A=

Informative References

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

[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 = .

=0A= =0A=

=0A=

TOC

=0A=

Author's Address

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

	Abbie Barbir
	Nortel Networks
	3500 Carling Avenue
	Nepean, Ontario K2H 8E9
	Canada
Phone:	+1 613 763 5229
EMail:	abbieb@nortelnetworks.com<= /td>

=0A= =0A=

=0A=

TOC

=0A=

Appendix = A. Acknowledgements

=0A= =0A=

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. =0A= =0A= =0A=

=0A=

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

=0A=

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

=0A=

TOC

=0A=

Intellectual Property Statement

=0A=

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

=0A=

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

=0A=

Full Copyright Statement

=0A=

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

=0A=

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

=0A=

=0A= This document and the information contained herein is provided on an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

=0A=

Acknowledgement

=0A=

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

=0A= =0A= =0A= ------_=_NextPart_000_01C3122B.E0E446BA Content-Type: text/plain; name="draft-ietf-opes-tracing-00-may4-2003.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-tracing-00-may4-2003.txt" Content-Transfer-Encoding: quoted-printable 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] =0C 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] =0C 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] =0C 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] =0C 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] =0C 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] =0C 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] =0C 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] =0C 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] =0C 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] =0C 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] =0C 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] =0C Internet-Draft OPES Tracing May = 2003 4. Security Considerations Barbir Expires November 2, 2003 [Page = 13] =0C 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] =0C 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] =0C 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@nortelnetworks.com Barbir Expires November 2, 2003 [Page = 16] =0C 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] =0C 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] =0C 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] =0C ------_=_NextPart_000_01C3122B.E0E446BA-- From owner-ietf-openproxy@mail.imc.org Mon May 5 06:38:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28672 for ; Mon, 5 May 2003 06:37:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CdO3-00051V-00 for opes-archive@ietf.org; Mon, 05 May 2003 06:39:59 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19CdNs-00051Q-00 for opes-archive@ietf.org; Mon, 05 May 2003 06:39:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45ARpi2077660 for ; Mon, 5 May 2003 03:27:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45ARp5c077659 for ietf-openproxy-bks; Mon, 5 May 2003 03:27:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h45ARmi2077651 for ; Mon, 5 May 2003 03:27:49 -0700 (PDT) (envelope-from martin.stecher@webwasher.com) Received: from hermes.webwasher.com [192.168.1.3] id SLGUTV68; 05 May 2003 12:27:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OCP transport nomination Date: Mon, 5 May 2003 12:24:02 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02E8FD4C3@hermes.webwasher.com> Thread-Topic: OCP transport nomination Thread-Index: AcMKfEVUmjBipdAuQZO9sBdP3aKWVAIdJW2w From: "Martin Stecher" To: "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h45ARoi2077654 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 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@measurement-factory.com] > Sent: Thursday, April 24, 2003 5:41 PM > To: ietf-openproxy@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. > From owner-ietf-openproxy@mail.imc.org Mon May 5 12:45:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07408 for ; Mon, 5 May 2003 12:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cj7o-0006xK-00 for opes-archive@ietf.org; Mon, 05 May 2003 12:47:36 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Cj7d-0006x9-00 for opes-archive@ietf.org; Mon, 05 May 2003 12:47:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45GaPi2001229 for ; Mon, 5 May 2003 09:36:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45GaPPO001227 for ietf-openproxy-bks; Mon, 5 May 2003 09:36:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45GaNi2001221 for ; Mon, 5 May 2003 09:36:23 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h45GaO2R070380; Mon, 5 May 2003 10:36:24 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h45GaN1h070379; Mon, 5 May 2003 10:36:23 -0600 (MDT) (envelope-from rousskov) Date: Mon, 5 May 2003 10:36:23 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: RE: OCP transport nomination In-Reply-To: <72992B39BBD9294BB636A960E89AE02E8FD4C3@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02E8FD4C3@hermes.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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. From owner-ietf-openproxy@mail.imc.org Mon May 5 15:28:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13442 for ; Mon, 5 May 2003 15:28:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ClfP-00005G-00 for opes-archive@ietf.org; Mon, 05 May 2003 15:30:27 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19ClfE-00004a-00 for opes-archive@ietf.org; Mon, 05 May 2003 15:30:16 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45JHqi2006148 for ; Mon, 5 May 2003 12:17:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45JHq0f006147 for ietf-openproxy-bks; Mon, 5 May 2003 12:17:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45JHpi2006142 for ; Mon, 5 May 2003 12:17:51 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h45JRdn1020917; Mon, 5 May 2003 13:27:40 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h45JJJL05894; Mon, 5 May 2003 13:19:19 -0600 Date: Mon, 5 May 2003 13:19:19 -0600 Message-Id: <200305051919.h45JJJL05894@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: RE: OCP transport nomination Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 From owner-ietf-openproxy@mail.imc.org Mon May 5 16:27:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14888 for ; Mon, 5 May 2003 16:27:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CmaD-0000Zb-00 for opes-archive@ietf.org; Mon, 05 May 2003 16:29:09 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Cm6D-0000GO-00 for opes-archive@ietf.org; Mon, 05 May 2003 15:58:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Jmsi2007288 for ; Mon, 5 May 2003 12:48:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45JmsgC007287 for ietf-openproxy-bks; Mon, 5 May 2003 12:48:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Jmqi2007282 for ; Mon, 5 May 2003 12:48:53 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h45JlV2R075877; Mon, 5 May 2003 13:47:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h45JlVSf075876; Mon, 5 May 2003 13:47:31 -0600 (MDT) (envelope-from rousskov) Date: Mon, 5 May 2003 13:47:31 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: OCP transport nomination In-Reply-To: <200305051919.h45JJJL05894@localhost.localdomain> Message-ID: References: <200305051919.h45JJJL05894@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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): > 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. From owner-ietf-openproxy@mail.imc.org Mon May 5 16:29:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15150 for ; Mon, 5 May 2003 16:29:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CmcG-0000iE-00 for opes-archive@ietf.org; Mon, 05 May 2003 16:31:16 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Cmc5-0000hq-00 for opes-archive@ietf.org; Mon, 05 May 2003 16:31:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45KKoi2008221 for ; Mon, 5 May 2003 13:20:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45KKolp008220 for ietf-openproxy-bks; Mon, 5 May 2003 13:20:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45KKni2008215 for ; Mon, 5 May 2003 13:20:49 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h45KUcn1023317; Mon, 5 May 2003 14:30:38 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h45KMH308970; Mon, 5 May 2003 14:22:17 -0600 Date: Mon, 5 May 2003 14:22:17 -0600 Message-Id: <200305052022.h45KMH308970@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: RE: OCP transport nomination Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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): > > > In this message you referred to "the MIT license"; what did you mean? From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: BEEP as OCP transport Date: Thu, 17 Apr 2003 12:22:09 -0600 (MDT) In-Reply-To: <20030417102820.064ae9ed.mrose@dbc.mtview.ca.us> Message-ID: > > 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. From owner-ietf-openproxy@mail.imc.org Mon May 5 16:50:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15764 for ; Mon, 5 May 2003 16:50:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cmwy-0000pk-00 for opes-archive@ietf.org; Mon, 05 May 2003 16:52:40 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Cmwn-0000ph-00 for opes-archive@ietf.org; Mon, 05 May 2003 16:52:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Keli2008735 for ; Mon, 5 May 2003 13:40:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45KellA008734 for ietf-openproxy-bks; Mon, 5 May 2003 13:40:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Keji2008728 for ; Mon, 5 May 2003 13:40:45 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h45KejV8000838; Mon, 5 May 2003 13:40:45 -0700 (PDT) Date: Mon, 5 May 2003 13:40:45 -0700 From: Marshall Rose To: "The Purple Streak, Hilarie Orman" Cc: rousskov@measurement-factory.com, ietf-openproxy@imc.org Subject: Re: OCP transport nomination Message-Id: <20030505134045.4156600a.mrose@dbc.mtview.ca.us> In-Reply-To: <200305052022.h45KMH308970@localhost.localdomain> References: <200305052022.h45KMH308970@localhost.localdomain> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ 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". > > > > > > ... 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 From owner-ietf-openproxy@mail.imc.org Mon May 5 16:52:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15936 for ; Mon, 5 May 2003 16:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CmyO-0000sb-00 for opes-archive@ietf.org; Mon, 05 May 2003 16:54:08 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19CmyD-0000rY-00 for opes-archive@ietf.org; Mon, 05 May 2003 16:53:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Kg1i2008764 for ; Mon, 5 May 2003 13:42:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45Kg1kv008763 for ietf-openproxy-bks; Mon, 5 May 2003 13:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h45Kfwi2008754 for ; Mon, 5 May 2003 13:41:59 -0700 (PDT) (envelope-from martin.stecher@webwasher.com) Received: from hermes.webwasher.com [192.168.1.3] id MS9V9JYG; 05 May 2003 22:42:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: OCP transport nomination Date: Mon, 5 May 2003 22:38:26 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> Thread-Topic: OCP transport nomination Thread-Index: AcMTJAmlDBSXqQPoQ0SIB+wd+vnf7QAH86Xw From: "Martin Stecher" To: "Alex Rousskov" , "OPES WG (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h45Kg0i2008756 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit 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 From owner-ietf-openproxy@mail.imc.org Mon May 5 17:33:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17135 for ; Mon, 5 May 2003 17:33:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cnc8-00017A-00 for opes-archive@ietf.org; Mon, 05 May 2003 17:35:13 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Cnby-00016o-00 for opes-archive@ietf.org; Mon, 05 May 2003 17:35:02 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45LOvi2010574 for ; Mon, 5 May 2003 14:24:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45LOvfQ010573 for ietf-openproxy-bks; Mon, 5 May 2003 14:24:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45LOti2010568 for ; Mon, 5 May 2003 14:24:55 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h45LOuV8000946; Mon, 5 May 2003 14:24:56 -0700 (PDT) Date: Mon, 5 May 2003 14:24:56 -0700 From: Marshall Rose To: "Martin Stecher" Cc: ietf-openproxy@imc.org Subject: Re: AW: OCP transport nomination Message-Id: <20030505142456.3353fefe.mrose@dbc.mtview.ca.us> In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ 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 From owner-ietf-openproxy@mail.imc.org Mon May 5 17:58:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17787 for ; Mon, 5 May 2003 17:58:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Co0N-0001GJ-00 for opes-archive@ietf.org; Mon, 05 May 2003 18:00:15 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Co0C-0001Fv-00 for opes-archive@ietf.org; Mon, 05 May 2003 18:00:04 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45LmWi2011145 for ; Mon, 5 May 2003 14:48:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45LmW7M011144 for ietf-openproxy-bks; Mon, 5 May 2003 14:48:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45LmVi2011138 for ; Mon, 5 May 2003 14:48:31 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h45Lw8n1026403; Mon, 5 May 2003 15:58:10 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h45LnkS13588; Mon, 5 May 2003 15:49:46 -0600 Date: Mon, 5 May 2003 15:49:46 -0600 Message-Id: <200305052149.h45LnkS13588@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: mrose@dbc.mtview.ca.us Cc: ietf-openproxy@imc.org, rousskov@measurement-factory.com In-reply-to: Yourmessage <20030505134045.4156600a.mrose@dbc.mtview.ca.us> Subject: Re: OCP transport nomination Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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". > > > > > > > > > ... > 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. From owner-ietf-openproxy@mail.imc.org Mon May 5 18:25:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19409 for ; Mon, 5 May 2003 18:25:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CoR2-0001QB-00 for opes-archive@ietf.org; Mon, 05 May 2003 18:27:48 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19CoQr-0001Q0-00 for opes-archive@ietf.org; Mon, 05 May 2003 18:27:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45MIui2011955 for ; Mon, 5 May 2003 15:18:56 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45MIuka011954 for ietf-openproxy-bks; Mon, 5 May 2003 15:18:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45MIti2011949 for ; Mon, 5 May 2003 15:18:55 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h45MIuV8001101; Mon, 5 May 2003 15:18:56 -0700 (PDT) Date: Mon, 5 May 2003 15:18:55 -0700 From: Marshall Rose To: "The Purple Streak, Hilarie Orman" Cc: ietf-openproxy@imc.org, rousskov@measurement-factory.com Subject: Re: OCP transport nomination Message-Id: <20030505151855.289f773b.mrose@dbc.mtview.ca.us> In-Reply-To: <200305052149.h45LnkS13588@localhost.localdomain> References: <20030505134045.4156600a.mrose@dbc.mtview.ca.us> <200305052149.h45LnkS13588@localhost.localdomain> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ speaking as the beep guy... ] > OK, then there's no specification of the user-BEEP API for using TLS. there is no specification of the user-BEEP API for XYZ, regardless of the value of XYZ. > 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. isn't that sort of stuff up to each implementor? isn't the job of the specification suppose to say things like what options are allowed, without mandating a particular api, calling convention, etc.? /mtr From owner-ietf-openproxy@mail.imc.org Mon May 5 23:25:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25527 for ; Mon, 5 May 2003 23:25:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ct7Z-0002sc-00 for opes-archive@ietf.org; Mon, 05 May 2003 23:28:01 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Ct7O-0002sJ-00 for opes-archive@ietf.org; Mon, 05 May 2003 23:27:50 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h463GJi2019927 for ; Mon, 5 May 2003 20:16:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h463GJr9019926 for ietf-openproxy-bks; Mon, 5 May 2003 20:16:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h463GHi2019919 for ; Mon, 5 May 2003 20:16:18 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com ([135.104.20.67]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HEG00AMZ3R0PS@mtaout04.icomcast.net> for ietf-openproxy@imc.org; Mon, 05 May 2003 23:16:13 -0400 (EDT) Date: Mon, 05 May 2003 23:16:13 -0400 From: Markus Hofmann Subject: Re: AW: OCP transport nomination In-reply-to: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> To: OPES Group Message-id: <3EB728FD.9070104@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Hi, generally, I'd hesitate to dismiss or to deviate from an established standard just to get the protocol syntax closer to something a group of developers is already familiar with. If an existing protocol fits our needs, let's take advantage of it and use it the way it is. If it doesn't really fit our needs, we might be better off defining something new (rather than trying to tweak an existing approach to our needs). From the discussions so far, it seems that the functionality and the features provided by BEEP mostly fit our needs. The main concern seems to be about XML related performance and implementation overhead. An option might be to use XML only for BEEP's channel management. Would this address the performance concerns? Are there other fundamental issues that would speak against using BEEP and justify a new protocol (or suggest using another existing protocol)? -Markus Martin Stecher wrote: > 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 > > From owner-ietf-openproxy@mail.imc.org Tue May 6 00:48:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26589 for ; Tue, 6 May 2003 00:48:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CuPG-00037C-00 for opes-archive@ietf.org; Tue, 06 May 2003 00:50:23 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19CuP6-000375-00 for opes-archive@ietf.org; Tue, 06 May 2003 00:50:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h464cFi2022114 for ; Mon, 5 May 2003 21:38:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h464cFIi022113 for ietf-openproxy-bks; Mon, 5 May 2003 21:38:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h464cDi2022108 for ; Mon, 5 May 2003 21:38:14 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h464cH2R088546; Mon, 5 May 2003 22:38:17 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h464cGEH088545; Mon, 5 May 2003 22:38:16 -0600 (MDT) (envelope-from rousskov) Date: Mon, 5 May 2003 22:38:16 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Re: AW: OCP transport nomination In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 5 May 2003, Martin Stecher wrote: > > 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. Good point. > 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 agree. The ideal protocol should make it easy and efficient to "skip" or "extract" complete OCP messages without much parsing. > > 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. The worst case scenario :-). > 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 Comparing the above to reasons/arguments, it seems to me that the second is of much lesser importance. The second argument is less technical and more of a gamble: ICAP developers can be turned off by even small changes to the existing protocol (NetApp and Akamai are examples of how [ICAP/1.0] changes [compared to ICAP/0.9] alienated a part of the protocol community, I guess). On the other hand, most developers are probably proficient enough to handle whatever protocol we come up with, from scratch. Even if you disagree with the above comparison, I would still suggest that we try to agree on the XML issue first and resolve the "ICAP path" disagreements (if any) later. More on this in an XML-dedicated message that follows. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 00:51:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26619 for ; Tue, 6 May 2003 00:51:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CuRx-00037t-00 for opes-archive@ietf.org; Tue, 06 May 2003 00:53:09 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19CuRm-00037o-00 for opes-archive@ietf.org; Tue, 06 May 2003 00:52:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h464gqi2022214 for ; Mon, 5 May 2003 21:42:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h464gquL022213 for ietf-openproxy-bks; Mon, 5 May 2003 21:42:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h464goi2022205 for ; Mon, 5 May 2003 21:42:51 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h464gs2R088676 for ; Mon, 5 May 2003 22:42:54 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h464gsGq088675; Mon, 5 May 2003 22:42:54 -0600 (MDT) (envelope-from rousskov) Date: Mon, 5 May 2003 22:42:54 -0600 (MDT) From: Alex Rousskov To: "OPES WG (E-mail)" Subject: Using XML in OCP transport In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We have already heard several opinions (in my simplified rendering and interpretation): - XML is "not a big deal", everybody is using it [Marshall] - XML may be "too slow" for OCP [Hilarie] - XML is an "overkill" for the task [Martin] - we do not have to use XML for anything other than BEEP channel management [Marshall] - supporting just channel management means supporting nearly full XML specs if we care about compliance and interoperability [Alex] - other? If we can make a decision regarding XML use, it will simplify transport protocol choice because we would be able to ignore whether the candidates are using XML (if [limited] XML use is approved) or not (if all candidates do not use XML since its use was not approved). Is using XML a show-stopper? How are we going to decide? Does anybody have a suggestion for a process to ensure that "to use or not to use XML?" arguments are resolved? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 01:13:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26879 for ; Tue, 6 May 2003 01:13:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CunX-0003B7-00 for opes-archive@ietf.org; Tue, 06 May 2003 01:15:27 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19CunM-0003B4-00 for opes-archive@ietf.org; Tue, 06 May 2003 01:15:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4656ri2022770 for ; Mon, 5 May 2003 22:06:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4656rkv022769 for ietf-openproxy-bks; Mon, 5 May 2003 22:06:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4656pi2022763 for ; Mon, 5 May 2003 22:06:52 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h4656p2R089270; Mon, 5 May 2003 23:06:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h4656pqf089269; Mon, 5 May 2003 23:06:51 -0600 (MDT) (envelope-from rousskov) Date: Mon, 5 May 2003 23:06:51 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: AW: OCP transport nomination In-Reply-To: <20030505142456.3353fefe.mrose@dbc.mtview.ca.us> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> <20030505142456.3353fefe.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 5 May 2003, Marshall Rose wrote: > > 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. I wish the situation was that simple/straightforward. I do not think it is. Your comments assume that "beep-like things" are well-defined. They are not! We are, in fact, trying to answer that very question: "Is OCP doing something that BEEP is appropriate transport for?" Clearly, BEEP RFC itself does not (cannot) answer that question -- defined BEEP scope is too broad and not specific enough. Do you, personally, think that the answer is clear? There are many aspects to consider, but the primary ones seem to be: 1) XML (required in BEEP) 2) ICAP migration (more smooth with OCPTRAN than with BEEP) 3) message exchange (a single channel may be required for each data and metadata exchange, in addition to control channel(s); OCPTRAN can have better, more natural and efficient mapping) 4) profile reuse (to support transport security, etc.) Since channel management (closely related to item 3) requires XML, and since OCP is going to be different from ICAP anyway, I believe the two biggest issues are XML and profile reuse. Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 01:17:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26915 for ; Tue, 6 May 2003 01:17:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Curp-0003Bd-00 for opes-archive@ietf.org; Tue, 06 May 2003 01:19:53 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Cure-0003BT-00 for opes-archive@ietf.org; Tue, 06 May 2003 01:19:42 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h465Aui2022885 for ; Mon, 5 May 2003 22:10:56 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h465Aucu022884 for ietf-openproxy-bks; Mon, 5 May 2003 22:10:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h465Asi2022878 for ; Mon, 5 May 2003 22:10:54 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h465Au2R089294; Mon, 5 May 2003 23:10:56 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h465AubW089293; Mon, 5 May 2003 23:10:56 -0600 (MDT) (envelope-from rousskov) Date: Mon, 5 May 2003 23:10:56 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: OCP transport nomination In-Reply-To: <200305052149.h45LnkS13588@localhost.localdomain> Message-ID: References: <200305052149.h45LnkS13588@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 5 May 2003, The Purple Streak, Hilarie Orman wrote: > 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. This is probably true and smells similar to how HTTP can be wrapped in TLS/SSL. Still, we would have to write some documents explaining how TLS or other encodings are applied/negotiated/configured in OCP context. BEEP folks did that legwork for us. Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 01:35:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27134 for ; Tue, 6 May 2003 01:35:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cv9D-0003FC-00 for opes-archive@ietf.org; Tue, 06 May 2003 01:37:51 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Cv8y-0003Ej-00 for opes-archive@ietf.org; Tue, 06 May 2003 01:37:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h465SZi2023541 for ; Mon, 5 May 2003 22:28:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h465SZ0i023540 for ietf-openproxy-bks; Mon, 5 May 2003 22:28:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h465SYi2023535 for ; Mon, 5 May 2003 22:28:34 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h465Sb2R089776; Mon, 5 May 2003 23:28:37 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h465SboX089775; Mon, 5 May 2003 23:28:37 -0600 (MDT) (envelope-from rousskov) Date: Mon, 5 May 2003 23:28:37 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: AW: OCP transport nomination In-Reply-To: <3EB728FD.9070104@mhof.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> <3EB728FD.9070104@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 5 May 2003, Markus Hofmann wrote: > From the discussions so far, it seems that the functionality and the > features provided by BEEP mostly fit our needs. The main concern > seems to be about XML related performance and implementation > overhead. An option might be to use XML only for BEEP's channel > management. Would this address the performance concerns? Probably not if my understanding of how to naturally map OCP to BEEP is correct. A natural mapping would require creation of a separate channel for any [meta]data that needs to be passed to the other OCP agent, asynchronously or semi-asynchronously: - original application message data - original application message metadata - adapted application message(s) data - adapted application message(s) metadata Ideally, we need one channel for each because, unfortunately, BEEP does not allow mixing BEEP message frames from different BEEP messages within one channel, and OCP needs to mix [large] data, [large] metadata, and [small] control messages. We can reduce the mixing requirements somewhat (e.g., by requiring that all metadata is known before data is sent), but we would still end up with 2-3 extra channels per OCP transaction. If channel establishment is slow (because of XML or whatever), we have a problem. The only way to solve this performance problem is to reuse channels across OCP transactions. This is usually possible from BEEP point of view (AFAIK), but makes the protocol more difficult to understand and implement because you lose nice encapsulation of channels within OCP transaction. An alternative to channel reuse is an "unnatural" mapping to BEEP that, essentially, does not use much of the BEEP core features (such as message framing) but rather re-implements them hidden from BEEP, inside simple BEEP messages, to work around BEEP message exchange limitations. Sort of like doing IP-over-IP encapsulation, I guess. > Are there other fundamental issues that would speak against using > BEEP and justify a new protocol (or suggest using another existing > protocol)? Another fundamental issue FOR using BEEP is reuse of security-related profiles (though Hilarie may disagree that there is enough to reuse). Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 03:12:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10300 for ; Tue, 6 May 2003 03:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CweN-0003t4-00 for opes-archive@ietf.org; Tue, 06 May 2003 03:14:07 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19CweC-0003su-00 for opes-archive@ietf.org; Tue, 06 May 2003 03:13:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4673Mi2033864 for ; Tue, 6 May 2003 00:03:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4673Mir033863 for ietf-openproxy-bks; Tue, 6 May 2003 00:03:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4673Li2033858 for ; Tue, 6 May 2003 00:03:21 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h467DGn1010551; Tue, 6 May 2003 01:13:16 -0600 Received: (from ho@localhost) by localhost.localdomain (8.11.6/8.11.6) id h4674ih08343; Tue, 6 May 2003 01:04:44 -0600 Date: Tue, 6 May 2003 01:04:44 -0600 Message-Id: <200305060704.h4674ih08343@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: markus@mhof.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <3EB728FD.9070104@mhof.com> Subject: Re: AW: OCP transport nomination Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think the issue is that while BEEP can be made to fit our needs, as can many other things, it seems slightly contorted, and it might well be easier to define exactly what we need. That's where the discussion is, thus far. I'd be interested in hearing opinions about "I could build OCP on BEEP in X weeks". That was a problem with ICAP - it could almost be built cleanly on HTTP with little work, but that then little by little it drifted away. I don't see that BEEP provides any particular help for security. I think that we definitely need to be XML-free in the sense of being able to write the header parsing code using a few simple, efficient C routines. It's OK if a full-weight XML parser can also do the job - this isn't angle bracket phobia, just a desire to spend more CPU time on actual OPES services than on header parsing. Hilarie From owner-ietf-openproxy@mail.imc.org Tue May 6 11:14:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25692 for ; Tue, 6 May 2003 11:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D4At-0007gO-00 for opes-archive@ietf.org; Tue, 06 May 2003 11:16:11 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D4As-0007gL-00 for opes-archive@ietf.org; Tue, 06 May 2003 11:16:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46F58i2081490 for ; Tue, 6 May 2003 08:05:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46F58X5081489 for ietf-openproxy-bks; Tue, 6 May 2003 08:05:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46F57i2081484 for ; Tue, 6 May 2003 08:05:07 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h46F575r001665; Tue, 6 May 2003 08:05:07 -0700 (PDT) Date: Tue, 6 May 2003 08:05:07 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: AW: OCP transport nomination Message-Id: <20030506080507.2e471e37.mrose@dbc.mtview.ca.us> In-Reply-To: References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> <20030505142456.3353fefe.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ speaking as the beep guy... ] > I wish the situation was that simple/straightforward. I do not think > it is. Your comments assume that "beep-like things" are well-defined. > They are not! We are, in fact, trying to answer that very question: > "Is OCP doing something that BEEP is appropriate transport for?" > Clearly, BEEP RFC itself does not (cannot) answer that question -- > defined BEEP scope is too broad and not specific enough. Do you, > personally, think that the answer is clear? if there were a clear description of what ocp's requirements are, then it would be trivial to answer these questions. in general, if you come up with a new connection-oriented protocol that does things like sasl, tls, framing, and possibly multiplexing, then you are doing beep-like things. just so we're clear: later on today, i'm going back to being the process guy, and markus can see if he can get the working group to decide what to do. > There are many aspects to consider, but the primary ones seem to be: > > 1) XML (required in BEEP) anyone who thinks that implementing xml to support beep is a problem has a very skewed set of priorities... > 2) ICAP migration (more smooth with OCPTRAN than with BEEP) sure. > 3) message exchange (a single channel may be required for each > data and metadata exchange, in addition to control > channel(s); OCPTRAN can have better, more natural > and efficient mapping) hmmm... > 4) profile reuse (to support transport security, etc.) anything you can do with tls or sasl, you can do with tls or sasl under beep. > Since channel management (closely related to item 3) requires XML, and > since OCP is going to be different from ICAP anyway, I believe the two > biggest issues are XML and profile reuse. amusingly enough, these are the two i see as non-issues... /mtr From owner-ietf-openproxy@mail.imc.org Tue May 6 11:14:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25744 for ; Tue, 6 May 2003 11:14:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D4BU-0007gg-00 for opes-archive@ietf.org; Tue, 06 May 2003 11:16:48 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D4BT-0007gd-00 for opes-archive@ietf.org; Tue, 06 May 2003 11:16:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46F4ci2081450 for ; Tue, 6 May 2003 08:04:38 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46F4cRs081449 for ietf-openproxy-bks; Tue, 6 May 2003 08:04:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46F4ai2081444 for ; Tue, 6 May 2003 08:04:36 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46F4bHa022333 for ; Tue, 6 May 2003 11:04:37 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46F4UUf076354 for ; Tue, 6 May 2003 11:04:30 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46F4TQ4003643 for ; Tue, 6 May 2003 11:04:30 -0400 (EDT) Message-ID: <3EB7CF35.6080604@mhof.com> Date: Tue, 06 May 2003 11:05:25 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: AW: OCP transport nomination References: <200305060704.h4674ih08343@localhost.localdomain> In-Reply-To: <200305060704.h4674ih08343@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The Purple Streak, Hilarie Orman wrote: > I think the issue is that while BEEP can be made to fit our needs, as > can many other things, it seems slightly contorted, and it might well > be easier to define exactly what we need. My concern with that approach is that we re-invent many things that have already been adressed before, and that the WG spends lots of time defining a transport rather than defining the actual OCP. > I don't see that BEEP provides any particular help for security. What exactly is missing in BEEP? Could this be build on top of BEEP? > I think that we definitely need to be XML-free in the sense of being > able to write the header parsing code using a few simple, efficient C > routines. It's OK if a full-weight XML parser can also do the job - > this isn't angle bracket phobia, just a desire to spend more CPU time on > actual OPES services than on header parsing. Is parsing a few XML messages for BEEP's channel management such a big problem that it would justify defining an alternate protocol over an existing one? -Markus From owner-ietf-openproxy@mail.imc.org Tue May 6 11:23:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26064 for ; Tue, 6 May 2003 11:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D4Jb-0007jk-00 for opes-archive@ietf.org; Tue, 06 May 2003 11:25:11 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D4Jb-0007jc-00 for opes-archive@ietf.org; Tue, 06 May 2003 11:25:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FFTi2081982 for ; Tue, 6 May 2003 08:15:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46FFTSm081981 for ietf-openproxy-bks; Tue, 6 May 2003 08:15:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FFSi2081975 for ; Tue, 6 May 2003 08:15:28 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h46FFO5r001701; Tue, 6 May 2003 08:15:25 -0700 (PDT) Date: Tue, 6 May 2003 08:15:24 -0700 From: Marshall Rose To: "The Purple Streak, Hilarie Orman" Cc: markus@mhof.com, ietf-openproxy@imc.org Subject: Re: AW: OCP transport nomination Message-Id: <20030506081524.5968b0b9.mrose@dbc.mtview.ca.us> In-Reply-To: <200305060704.h4674ih08343@localhost.localdomain> References: <3EB728FD.9070104@mhof.com> <200305060704.h4674ih08343@localhost.localdomain> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ next to last message, speaking as the beep guy ...] > I think the issue is that while BEEP can be made to fit our needs, as > can many other things, it seems slightly contorted, and it might well > be easier to define exactly what we need. That's where the discussion > is, thus far. I'd be interested in hearing opinions about "I could > build OCP on BEEP in X weeks". That was a problem with ICAP - it could > almost be built cleanly on HTTP with little work, but that then little by > little it drifted away. this probably won't come as a surprise to anyone, but speed and innovation aren't exactly hallmarks of this working group. when you find yourself in a situation like that, the absolute worst thing you can do is go off and reinvent a lot of old stuff. if beep doesn't work, don't use beep. if the answer is "we'll define exactly what we need", then: YOU HAVE ASKED THE WRONG QUESTION BECAUSE YOU WILL NEVER FINISH where i interested in seeing this work complete, i would be leveraging every existing open standards thing i could get my hands on. i wouldn't care at all about optimality. i would care about getting the job done before the IESG wises up and figures out that this working group isn't going to succeed. if i could figure out a way to make this thing work sensibly with telnet, i'd do it. but, hey, that's just me. > I don't see that BEEP provides any particular help for security. you're right: beep doesn't make things more secure. what it does is integrate tls/sasl into a framing/command mechanism, so working groups that have better things to do (and know they have better things to do) can work on better things to do. > I think that we definitely need to be XML-free in the sense of being > able to write the header parsing code using a few simple, efficient C > routines. It's OK if a full-weight XML parser can also do the job - > this isn't angle bracket phobia, just a desire to spend more CPU time on > actual OPES services than on header parsing. XML is not the problem here. /mtr From owner-ietf-openproxy@mail.imc.org Tue May 6 11:30:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26287 for ; Tue, 6 May 2003 11:30:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D4Qd-0007mv-00 for opes-archive@ietf.org; Tue, 06 May 2003 11:32:27 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D4Qc-0007ms-00 for opes-archive@ietf.org; Tue, 06 May 2003 11:32:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FM7i2082198 for ; Tue, 6 May 2003 08:22:07 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46FM7HA082197 for ietf-openproxy-bks; Tue, 6 May 2003 08:22:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46FM5i2082192 for ; Tue, 6 May 2003 08:22:06 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46FM7Ha022493 for ; Tue, 6 May 2003 11:22:07 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46FM0c6090484 for ; Tue, 6 May 2003 11:22:00 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46FM0Q4004306 for ; Tue, 6 May 2003 11:22:00 -0400 (EDT) Message-ID: <3EB7D34F.2020002@mhof.com> Date: Tue, 06 May 2003 11:22:55 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: AW: OCP transport nomination References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> <3EB728FD.9070104@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > If channel establishment is slow (because of XML or whatever), we have > a problem. The only way to solve this performance problem is to reuse > channels across OCP transactions. This is usually possible from BEEP > point of view (AFAIK), but makes the protocol more difficult to > understand and implement because you lose nice encapsulation of > channels within OCP transaction. Did we convince ourselves that this kind of XML usage is a serious (performance) problem? So far, we mostly speculated on the overhead and possible performance impact without having hard facts. Does anyone have concrete numbers or measurments to share? If we're not convinced that this is a big, serious problem, we might want to move on and focus our time and effort on getting OCP done (rather than defining a transport protocol). -Markus From owner-ietf-openproxy@mail.imc.org Tue May 6 12:19:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28252 for ; Tue, 6 May 2003 12:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5CZ-0000LA-00 for opes-archive@ietf.org; Tue, 06 May 2003 12:22:00 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D5CZ-0000L7-00 for opes-archive@ietf.org; Tue, 06 May 2003 12:21:59 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46G9Hi2084636 for ; Tue, 6 May 2003 09:09:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46G9HYu084635 for ietf-openproxy-bks; Tue, 6 May 2003 09:09:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46G9Gi2084629 for ; Tue, 6 May 2003 09:09:16 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h46G9F2R005131; Tue, 6 May 2003 10:09:15 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h46G9FRq005130; Tue, 6 May 2003 10:09:15 -0600 (MDT) (envelope-from rousskov) Date: Tue, 6 May 2003 10:09:15 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: AW: OCP transport nomination In-Reply-To: <20030506080507.2e471e37.mrose@dbc.mtview.ca.us> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> <20030505142456.3353fefe.mrose@dbc.mtview.ca.us> <20030506080507.2e471e37.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 6 May 2003, Marshall Rose wrote: > > I wish the situation was that simple/straightforward. I do not > > think it is. Your comments assume that "beep-like things" are > > well-defined. They are not! We are, in fact, trying to answer that > > very question: "Is OCP doing something that BEEP is appropriate > > transport for?" Clearly, BEEP RFC itself does not (cannot) answer > > that question -- defined BEEP scope is too broad and not specific > > enough. Do you, personally, think that the answer is clear? > > if there were a clear description of what ocp's requirements are, > then it would be trivial to answer these questions. This is a catch-22. If there were a final description of OCP requirements, we would not have to have this conversation. High-level requirements are not detailed enough. OCP details are not completely known yet. Many OCP aspects can be supported differently, depending on the transport protocol we chose. We know that OCP is for efficient asynchronous exchange of [possibly large] metadata, [possibly large] data, and small command messages. That is "clear" but not [precise] enough to say whether BEEP is the best way to proceed. > in general, if you come up with a new connection-oriented protocol > that does things like sasl, tls, framing, and possibly multiplexing, > then you are doing beep-like things. True. But BEEP is not an ideal transport for all connection-oriented protocols that do things like sasl, tls, framing, and multiplexing (no single transport can be!). BEEP designers had to make some choices that made BEEP imperfect in some beep-like environments. Most of these choices are well documented; use of XML and message exchange limitations are some of them. We have to decide whether those imperfections are major or minor in OCP case. > > There are many aspects to consider, but the primary ones seem to > > be: > > > > 1) XML (required in BEEP) > > anyone who thinks that implementing xml to support beep is a problem > has a very skewed set of priorities... Anyone who thinks that supporting XML comes for free has a very skewed set of applications. > > 2) ICAP migration (more smooth with OCPTRAN than with BEEP) > > sure. > > > > 3) message exchange (a single channel may be required for each > > data and metadata exchange, in addition to control > > channel(s); OCPTRAN can have better, more natural > > and efficient mapping) > > hmmm... > > > > 4) profile reuse (to support transport security, etc.) > > anything you can do with tls or sasl, you can do with tls or > sasl under beep. Yes, #4 is an argument for BEEP, not against it. OCPTRAN cannot reuse any profiles "as is" because OCPTRAN is a new protocol. The question is how much more work we would need to do if we start from scratch. Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 12:40:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28822 for ; Tue, 6 May 2003 12:40:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5WB-0000Sn-00 for opes-archive@ietf.org; Tue, 06 May 2003 12:42:16 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D5WB-0000Sk-00 for opes-archive@ietf.org; Tue, 06 May 2003 12:42:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GUli2086515 for ; Tue, 6 May 2003 09:30:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46GUl1Y086513 for ietf-openproxy-bks; Tue, 6 May 2003 09:30:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GUji2086506 for ; Tue, 6 May 2003 09:30:46 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h46GUk2R005610; Tue, 6 May 2003 10:30:46 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h46GUkG3005609; Tue, 6 May 2003 10:30:46 -0600 (MDT) (envelope-from rousskov) Date: Tue, 6 May 2003 10:30:46 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: Re: AW: OCP transport nomination In-Reply-To: <20030506081524.5968b0b9.mrose@dbc.mtview.ca.us> Message-ID: References: <3EB728FD.9070104@mhof.com> <200305060704.h4674ih08343@localhost.localdomain> <20030506081524.5968b0b9.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 6 May 2003, Marshall Rose wrote: > where i interested in seeing this work complete, i would be > leveraging every existing open standards thing i could get my hands > on. i wouldn't care at all about optimality. i would care about > getting the job done before the IESG wises up and figures out that > this working group isn't going to succeed. Why are you not suggesting that we simply use ICAP/1.0 as OCP, then? ICAP/1.0 (RFC 3507) exists, works, and is open. Personally, I think that it is far better for this group to be forced to close by the wise IESG than to produce OPES protocols that are not much better than the existing ones. It is better to produce nothing [new] than to just further dilute protocol set for OPES-like things. We have to build the "best" OPES protocols to justify this WG existence. Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 12:59:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29330 for ; Tue, 6 May 2003 12:59:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5pG-0000ao-00 for opes-archive@ietf.org; Tue, 06 May 2003 13:01:58 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D5pF-0000aj-00 for opes-archive@ietf.org; Tue, 06 May 2003 13:01:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GpEi2090434 for ; Tue, 6 May 2003 09:51:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46GpD1e090433 for ietf-openproxy-bks; Tue, 6 May 2003 09:51:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GpCi2090426 for ; Tue, 6 May 2003 09:51:12 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h46GpD2R006178; Tue, 6 May 2003 10:51:13 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h46GpDc5006177; Tue, 6 May 2003 10:51:13 -0600 (MDT) (envelope-from rousskov) Date: Tue, 6 May 2003 10:51:13 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: AW: OCP transport nomination In-Reply-To: <3EB7D34F.2020002@mhof.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> <3EB728FD.9070104@mhof.com> <3EB7D34F.2020002@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 6 May 2003, Markus Hofmann wrote: > Did we convince ourselves that this kind of XML usage is a serious > (performance) problem? So far, we mostly speculated on the overhead > and possible performance impact without having hard facts. Does > anyone have concrete numbers or measurments to share? I do not think anybody has. Some speculate that XML introduces no overheads. Some speculate that XML is expensive. I doubt it is possible to answer that question in general. Is XML an issue for reliable syslog? No, not usually. Would XML be an issue for TCP? Yes, in many environments. > If we're not convinced that this is a big, serious problem, we might > want to move on and focus our time and effort on getting OCP done > (rather than defining a transport protocol). This would imply that we suspect it is not a big problem. As of now, Hilarie and Martin have argued that it is. I will try to narrow down the disagreements in a separate message. Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 13:05:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29565 for ; Tue, 6 May 2003 13:05:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5uL-0000dL-00 for opes-archive@ietf.org; Tue, 06 May 2003 13:07:13 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D5uK-0000dI-00 for opes-archive@ietf.org; Tue, 06 May 2003 13:07:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GsKi2090963 for ; Tue, 6 May 2003 09:54:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46GsK4V090962 for ietf-openproxy-bks; Tue, 6 May 2003 09:54:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46GsJi2090954 for ; Tue, 6 May 2003 09:54:19 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h46GsK2R006198; Tue, 6 May 2003 10:54:20 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h46GsKUF006197; Tue, 6 May 2003 10:54:20 -0600 (MDT) (envelope-from rousskov) Date: Tue, 6 May 2003 10:54:20 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: Using XML in OCP transport In-Reply-To: <3EB7D34F.2020002@mhof.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEA@hermes.webwasher.com> <3EB728FD.9070104@mhof.com> <3EB7D34F.2020002@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 6 May 2003, Markus Hofmann wrote: > Is parsing a few XML messages for BEEP's channel management such a > big problem that it would justify defining an alternate protocol > over an existing one? Let me try to distill the question further, in hope to isolate the subset of XML-related issues that lack consensus. I will phrase these as assertions: 1 An OCP/BEEP implementation would parse simple, short XML fragments most of the time. 2 To be compliant, an OCP/BEEP implementation would have to be able to parse arbitrary XML, including malicious XML. 3 In 7 years, virtually every OCP/* agent will support XML for reasons unrelated to transport; that support may not be efficient (e.g., parsing of configuration files or generating logs). 4 It is possible to optimize parsing of simple, short XML fragments with known parsing goal (e.g., just to find the profile URIs and ignore everything else). 5 It is possible to optimize generation of simple, short XML fragments. 6 It is very tempting to use XML for OCP negotiations and other, mostly performance-unrelated OCP tasks _if_ XML has to be supported for transport reasons anyway. 7 The use of XML will initially alienate a noticeable fraction of the existing ICAP community Does anybody disagree with any of the above assertions? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue May 6 14:04:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01617 for ; Tue, 6 May 2003 14:04:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D6pz-000173-00 for opes-archive@ietf.org; Tue, 06 May 2003 14:06:47 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19D6py-000170-00 for opes-archive@ietf.org; Tue, 06 May 2003 14:06:46 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Hqai2094613 for ; Tue, 6 May 2003 10:52:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46HqaOh094612 for ietf-openproxy-bks; Tue, 6 May 2003 10:52:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from shego.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46HqYi2094607 for ; Tue, 6 May 2003 10:52:34 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h46HqZ5r002065; Tue, 6 May 2003 10:52:35 -0700 (PDT) Date: Tue, 6 May 2003 10:52:35 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: AW: OCP transport nomination Message-Id: <20030506105235.5cc41d97.mrose@dbc.mtview.ca.us> In-Reply-To: References: <3EB728FD.9070104@mhof.com> <200305060704.h4674ih08343@localhost.localdomain> <20030506081524.5968b0b9.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ speaking as the beep guy, final message... ] > > where i interested in seeing this work complete, i would be > > leveraging every existing open standards thing i could get my hands > > on. i wouldn't care at all about optimality. i would care about > > getting the job done before the IESG wises up and figures out that > > this working group isn't going to succeed. > > Why are you not suggesting that we simply use ICAP/1.0 as OCP, then? > ICAP/1.0 (RFC 3507) exists, works, and is open. and if it meets all the requirements (including stuff like security) and can pass iesg muster, then that's what the working group should use. > Personally, I think that it is far better for this group to be forced > to close by the wise IESG than to produce OPES protocols that are not > much better than the existing ones. It is better to produce nothing > [new] than to just further dilute protocol set for OPES-like things. > We have to build the "best" OPES protocols to justify this WG > existence. i have yet to attend an engineering meeting where the goal is the "best". the goal is never the "best". the goal is to get things right enough, cheap enough, and fast enough to solve enough of the problem and then move on. i have attended many research meetings, where the goal, as you might expect is the "best". fundamentally, i have to put the ietf and it's working groups into the engineering category. others' mileage may, of course, vary. /mtr From owner-ietf-openproxy@mail.imc.org Tue May 6 18:07:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11195 for ; Tue, 6 May 2003 18:07:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAd5-0002wp-00 for opes-archive@ietf.org; Tue, 06 May 2003 18:09:43 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DAd4-0002wm-00 for opes-archive@ietf.org; Tue, 06 May 2003 18:09:43 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Lt5i2004208 for ; Tue, 6 May 2003 14:55:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46Lt5Iu004207 for ietf-openproxy-bks; Tue, 6 May 2003 14:55:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h46Lt2i2004194 for ; Tue, 6 May 2003 14:55:04 -0700 (PDT) (envelope-from martin.stecher@webwasher.com) Received: from hermes.webwasher.com [192.168.1.3] id TUGQDJRK; 06 May 2003 23:54:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: AW: OCP transport nomination Date: Tue, 6 May 2003 23:51:24 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02EF54CED@hermes.webwasher.com> Thread-Topic: AW: OCP transport nomination Thread-Index: AcMT/Hc6tBcH+wZ5RRek82zlzWXnaQAG1CYg From: "Martin Stecher" To: "Marshall Rose" , "Alex Rousskov" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h46Lt4i2004203 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit That is going to become a philosophic discussion about engineering goals ;-) While my experiences as a software engineer contain always compromises and never included the theoretical best solution, it still has always been the goal to create the best under the given circumstances (usually means: having limited resources). Especially creating a protocol means to me to do something more than the absolute minimum, because others should benefit from it, now and in some future. And all upcoming users do also have their restrictions. So forcing those to implement a lot of new code, maybe including support of other libraries, which are only needed because this group wanted to have a minimum of work - that's a way I have question marks with whether OCP can be successful. But should the consensus be that the WG should just meet the minimum charted goals, then we should just update ICAP and create ICAP/1.1 which simply addresses the few open issues. [Even being the ICAP guy here, this is not my preferred way.] Martin > > [ speaking as the beep guy, final message... ] > > > > where i interested in seeing this work complete, i would be > > > leveraging every existing open standards thing i could > get my hands > > > on. i wouldn't care at all about optimality. i would care about > > > getting the job done before the IESG wises up and figures out that > > > this working group isn't going to succeed. > > > > Why are you not suggesting that we simply use ICAP/1.0 as OCP, then? > > ICAP/1.0 (RFC 3507) exists, works, and is open. > > and if it meets all the requirements (including stuff like > security) and > can pass iesg muster, then that's what the working group should use. > > > > Personally, I think that it is far better for this group to > be forced > > to close by the wise IESG than to produce OPES protocols > that are not > > much better than the existing ones. It is better to produce nothing > > [new] than to just further dilute protocol set for OPES-like things. > > We have to build the "best" OPES protocols to justify this WG > > existence. > > i have yet to attend an engineering meeting where the goal is the > "best". the goal is never the "best". the goal is to get things right > enough, cheap enough, and fast enough to solve enough of the > problem and > then move on. > > i have attended many research meetings, where the goal, as you might > expect is the "best". > > fundamentally, i have to put the ietf and it's working groups into the > engineering category. others' mileage may, of course, vary. > > /mtr > From owner-ietf-openproxy@mail.imc.org Tue May 6 18:07:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11225 for ; Tue, 6 May 2003 18:07:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAdF-0002wv-00 for opes-archive@ietf.org; Tue, 06 May 2003 18:09:53 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DAdE-0002ws-00 for opes-archive@ietf.org; Tue, 06 May 2003 18:09:53 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Ltsi2004227 for ; Tue, 6 May 2003 14:55:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46LtsH1004226 for ietf-openproxy-bks; Tue, 6 May 2003 14:55:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h46Ltqi2004221 for ; Tue, 6 May 2003 14:55:53 -0700 (PDT) (envelope-from martin.stecher@webwasher.com) Received: from hermes.webwasher.com [192.168.1.3] id 0R6K2N23; 06 May 2003 23:55:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: AW: Using XML in OCP transport Date: Tue, 6 May 2003 23:52:20 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02E8FD4E0@hermes.webwasher.com> Thread-Topic: Using XML in OCP transport Thread-Index: AcMT9G9++3rQPTkLSs+K7ng1bR7ESgAJb5Qw From: "Martin Stecher" To: "Alex Rousskov" , "OPES Group" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h46Ltri2004222 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h46Ltsi2004227 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA11225 I agree to all of your assertions. Martin > -----Ursprüngliche Nachricht----- > Von: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Gesendet: Dienstag, 6. Mai 2003 18:54 > An: OPES Group > Betreff: Re: Using XML in OCP transport > > > > > On Tue, 6 May 2003, Markus Hofmann wrote: > > > Is parsing a few XML messages for BEEP's channel management such a > > big problem that it would justify defining an alternate protocol > > over an existing one? > > Let me try to distill the question further, in hope to isolate the > subset of XML-related issues that lack consensus. I will phrase these > as assertions: > > 1 An OCP/BEEP implementation would parse simple, > short XML fragments most of the time. > > 2 To be compliant, an OCP/BEEP implementation would > have to be able to parse arbitrary XML, including > malicious XML. > > 3 In 7 years, virtually every OCP/* agent will support XML > for reasons unrelated to transport; that support may not > be efficient (e.g., parsing of configuration files or > generating logs). > > 4 It is possible to optimize parsing of simple, > short XML fragments with known parsing goal > (e.g., just to find the profile URIs and ignore > everything else). > > 5 It is possible to optimize generation of simple, > short XML fragments. > > 6 It is very tempting to use XML for OCP negotiations > and other, mostly performance-unrelated OCP tasks _if_ > XML has to be supported for transport reasons anyway. > > 7 The use of XML will initially alienate a noticeable > fraction of the existing ICAP community > > Does anybody disagree with any of the above assertions? > > Thanks, > > Alex. > From owner-ietf-openproxy@mail.imc.org Tue May 6 18:23:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12262 for ; Tue, 6 May 2003 18:23:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAsM-00032Z-00 for opes-archive@ietf.org; Tue, 06 May 2003 18:25:30 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DAsL-00032S-00 for opes-archive@ietf.org; Tue, 06 May 2003 18:25:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46MCCi2004784 for ; Tue, 6 May 2003 15:12:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46MCCcC004783 for ietf-openproxy-bks; Tue, 6 May 2003 15:12:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46MCAi2004778 for ; Tue, 6 May 2003 15:12:10 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h46MCD2R014750; Tue, 6 May 2003 16:12:13 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h46MCDXJ014749; Tue, 6 May 2003 16:12:13 -0600 (MDT) (envelope-from rousskov) Date: Tue, 6 May 2003 16:12:12 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: AW: Using XML in OCP transport In-Reply-To: <72992B39BBD9294BB636A960E89AE02E8FD4E0@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02E8FD4E0@hermes.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 6 May 2003, Martin Stecher wrote: > I agree to all of your assertions. Martin, Would it be fair to conclude, then, that your primary reason for avoiding XML in OCP is assertion #7 (the use of XML will initially alienate a noticeable fraction of the existing ICAP community)? My reasoning is that if all of the performance-related assertions below are true, then there is no performance problem with XML in OCP context: all performance problems can be solved by practical, real-world engineering. Such efforts are virtually always required to support any new protocol efficiently anyway. If there are no performance problems, then (based on you past postings), I assume your primary concern is migration of existing ICAP community (i.e., assertion #7). Is my reasoning correct? Thank you, Alex. > > 1 An OCP/BEEP implementation would parse simple, > > short XML fragments most of the time. > > > > 2 To be compliant, an OCP/BEEP implementation would > > have to be able to parse arbitrary XML, including > > malicious XML. > > > > 3 In 7 years, virtually every OCP/* agent will support XML > > for reasons unrelated to transport; that support may not > > be efficient (e.g., parsing of configuration files or > > generating logs). > > > > 4 It is possible to optimize parsing of simple, > > short XML fragments with known parsing goal > > (e.g., just to find the profile URIs and ignore > > everything else). > > > > 5 It is possible to optimize generation of simple, > > short XML fragments. > > > > 6 It is very tempting to use XML for OCP negotiations > > and other, mostly performance-unrelated OCP tasks _if_ > > XML has to be supported for transport reasons anyway. > > > > 7 The use of XML will initially alienate a noticeable > > fraction of the existing ICAP community > > > > Does anybody disagree with any of the above assertions? From owner-ietf-openproxy@mail.imc.org Tue May 6 19:21:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13801 for ; Tue, 6 May 2003 19:21:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DBmv-0003OQ-00 for opes-archive@ietf.org; Tue, 06 May 2003 19:23:57 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DBmu-0003ON-00 for opes-archive@ietf.org; Tue, 06 May 2003 19:23:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46N94i2006403 for ; Tue, 6 May 2003 16:09:04 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46N94XM006402 for ietf-openproxy-bks; Tue, 6 May 2003 16:09:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46N93i2006396 for ; Tue, 6 May 2003 16:09:03 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46N949Y073557 for ; Tue, 6 May 2003 19:09:05 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46N8vUf018434 for ; Tue, 6 May 2003 19:08:57 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h46N8vQ4024215 for ; Tue, 6 May 2003 19:08:57 -0400 (EDT) Message-ID: <3EB840C0.8020501@mhof.com> Date: Tue, 06 May 2003 19:09:52 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: AW: AW: OCP transport nomination References: <72992B39BBD9294BB636A960E89AE02EF54CED@hermes.webwasher.com> In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CED@hermes.webwasher.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, new stuff will be worked on if we can expect significant improvements; existing solutions will be re-used if they do fit (or possible improvements would be minimal). We've to focus on the *most important* challenges, there are more than enough to solve. Think there's consensus that OCP can provide enough benefits to justify it over simply extending ICAP. It remains questionable whether a new transport vehicle would provide similar benefits over existing solutions. We should be careful of not re-inventing another wheel, if the existing wheels already help us moving forward. Let's get back to the technical discussion and close on the transport issue - that's the best way to move forward and to show that the WG is making progress. -Markus Martin Stecher wrote: > That is going to become a philosophic discussion about engineering goals ;-) > > While my experiences as a software engineer contain always compromises and > never included the theoretical best solution, it still has always been the > goal to create the best under the given circumstances (usually means: > having limited resources). > > Especially creating a protocol means to me to do something more than the > absolute minimum, because others should benefit from it, now and in some > future. And all upcoming users do also have their restrictions. > So forcing those to implement a lot of new code, maybe including support > of other libraries, which are only needed because this group wanted to > have a minimum of work - that's a way I have question marks with whether > OCP can be successful. > > But should the consensus be that the WG should just meet the minimum > charted goals, then we should just update ICAP and create ICAP/1.1 which > simply addresses the few open issues. > [Even being the ICAP guy here, this is not my preferred way.] > > Martin > > >>[ speaking as the beep guy, final message... ] >> >> >>>>where i interested in seeing this work complete, i would be >>>>leveraging every existing open standards thing i could >> >>get my hands >> >>>>on. i wouldn't care at all about optimality. i would care about >>>>getting the job done before the IESG wises up and figures out that >>>>this working group isn't going to succeed. >>> >>>Why are you not suggesting that we simply use ICAP/1.0 as OCP, then? >>>ICAP/1.0 (RFC 3507) exists, works, and is open. >> >> >>and if it meets all the requirements (including stuff like >>security) and >>can pass iesg muster, then that's what the working group should use. >> >> >> >>>Personally, I think that it is far better for this group to >> >>be forced >> >>>to close by the wise IESG than to produce OPES protocols >> >>that are not >> >>>much better than the existing ones. It is better to produce nothing >>>[new] than to just further dilute protocol set for OPES-like things. >>>We have to build the "best" OPES protocols to justify this WG >>>existence. >> >>i have yet to attend an engineering meeting where the goal is the >>"best". the goal is never the "best". the goal is to get things right >>enough, cheap enough, and fast enough to solve enough of the >>problem and >>then move on. >> >>i have attended many research meetings, where the goal, as you might >>expect is the "best". >> >>fundamentally, i have to put the ietf and it's working groups into the >>engineering category. others' mileage may, of course, vary. >> >>/mtr >> > > > From owner-ietf-openproxy@mail.imc.org Wed May 7 04:35:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21000 for ; Wed, 7 May 2003 04:35:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DKQU-0006bV-00 for opes-archive@ietf.org; Wed, 07 May 2003 04:37:22 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DKQU-0006bS-00 for opes-archive@ietf.org; Wed, 07 May 2003 04:37:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h478Opi2048749 for ; Wed, 7 May 2003 01:24:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h478OpmZ048748 for ietf-openproxy-bks; Wed, 7 May 2003 01:24:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from wwsmtp.webwasher.com ([217.146.159.49]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h478Omi2048738 for ; Wed, 7 May 2003 01:24:49 -0700 (PDT) (envelope-from martin.stecher@webwasher.com) Received: from hermes.webwasher.com [192.168.1.3] id YPEB24WL; 07 May 2003 10:24:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: AW: Using XML in OCP transport Date: Wed, 7 May 2003 10:21:10 +0200 Message-ID: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> Thread-Topic: AW: Using XML in OCP transport Thread-Index: AcMUHB0EGjuPQwaDRaqjbH2hV+Eq5QAUFkDQ From: "Martin Stecher" To: "Alex Rousskov" , "OPES Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h478Ooi2048741 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Would it be fair to conclude, then, that your primary reason > for avoiding XML in OCP is assertion #7 (the use of XML will initially > alienate a noticeable fraction of the existing ICAP community)? My concern is that OCP will not be successful, if implementors don't like it or find it too complicated or too much work to implement. So yes, my primary reason is #7. But regarding new potential implementors it is more an issue of assertions #2 and maybe #6, meaning that an OCP implementation which takes it serious needs fully compliant XML support. For example: ICAP support in the Squid proxy added less than 1500 lines of code. Any idea what it will take to get OCP/BEEP into Squid? As far as I know there is no XML support in Squid yet. > > My reasoning is that if all of the performance-related assertions > below are true, then there is no performance problem with XML in OCP > context: all performance problems can be solved by practical, > real-world engineering. Such efforts are virtually always required to > support any new protocol efficiently anyway. If there are no > performance problems, then (based on you past postings), I assume your > primary concern is migration of existing ICAP community (i.e., > assertion #7). Is my reasoning correct? I agree and never said that BEEP is not efficient. I am not concerned about our own implementation although it will probably be somehow tricky to have an optimized XML parser for OCP and still passing the compliance test that probably/hopefully The Measurement Factory will come up with ;-) But evangelising others that this protocol is definitly the one they should use or migrate to, this task could be a little harder to me. That's my concern. Regards Martin > > Thank you, > > Alex. > > > > > 1 An OCP/BEEP implementation would parse simple, > > > short XML fragments most of the time. > > > > > > 2 To be compliant, an OCP/BEEP implementation would > > > have to be able to parse arbitrary XML, including > > > malicious XML. > > > > > > 3 In 7 years, virtually every OCP/* agent will support XML > > > for reasons unrelated to transport; that support may not > > > be efficient (e.g., parsing of configuration files or > > > generating logs). > > > > > > 4 It is possible to optimize parsing of simple, > > > short XML fragments with known parsing goal > > > (e.g., just to find the profile URIs and ignore > > > everything else). > > > > > > 5 It is possible to optimize generation of simple, > > > short XML fragments. > > > > > > 6 It is very tempting to use XML for OCP negotiations > > > and other, mostly performance-unrelated OCP tasks _if_ > > > XML has to be supported for transport reasons anyway. > > > > > > 7 The use of XML will initially alienate a noticeable > > > fraction of the existing ICAP community > > > > > > Does anybody disagree with any of the above assertions? > From owner-ietf-openproxy@mail.imc.org Wed May 7 10:33:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03430 for ; Wed, 7 May 2003 10:33:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47EBoi2077372 for ; Wed, 7 May 2003 07:11:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47EBoQT077371 for ietf-openproxy-bks; Wed, 7 May 2003 07:11:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47EBni2077365 for ; Wed, 7 May 2003 07:11:49 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47EBnHa034730 for ; Wed, 7 May 2003 10:11:49 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47EBhUf083869 for ; Wed, 7 May 2003 10:11:43 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47EBgQ4011257 for ; Wed, 7 May 2003 10:11:42 -0400 (EDT) Message-ID: <3EB91456.5010303@mhof.com> Date: Wed, 07 May 2003 10:12:38 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: AW: Using XML in OCP transport References: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Martin Stecher wrote: > My concern is that OCP will not be successful, if implementors > don't like it or find it too complicated or too much work to > implement. While I understand the point, question is whether this is so serious that it would justify to not use an existing solution, but to spend cycles on defining something similar (just with a different lock-and-feel). -Markus From owner-ietf-openproxy@mail.imc.org Wed May 7 12:21:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07357 for ; Wed, 7 May 2003 12:21:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DRhl-0002k4-00 for opes-archive@ietf.org; Wed, 07 May 2003 12:23:41 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DRhk-0002k1-00 for opes-archive@ietf.org; Wed, 07 May 2003 12:23:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47GAii2086691 for ; Wed, 7 May 2003 09:10:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47GAics086690 for ietf-openproxy-bks; Wed, 7 May 2003 09:10:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47GAgi2086683 for ; Wed, 7 May 2003 09:10:42 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h47GAh2R040627; Wed, 7 May 2003 10:10:43 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h47GAheO040626; Wed, 7 May 2003 10:10:43 -0600 (MDT) (envelope-from rousskov) Date: Wed, 7 May 2003 10:10:43 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: RE: AW: Using XML in OCP transport In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 7 May 2003, Martin Stecher wrote: > My concern is that OCP will not be successful, if implementors don't > like it or find it too complicated or too much work to implement. So > yes, my primary reason is #7. But regarding new potential > implementors it is more an issue of assertions #2 and maybe #6, > meaning that an OCP implementation which takes it serious needs > fully compliant XML support. > > For example: ICAP support in the Squid proxy added less than 1500 > lines of code. Any idea what it will take to get OCP/BEEP into > Squid? As far as I know there is no XML support in Squid yet. I would think it would take about the same 2000 lines, provided an existing XML and BEEP Core libraries are used and no session encryption is required. If Squid folks decide to optimize an XML parser for OCP, it would probably take another 500 lines, provided an inefficient XML library is still used for unexpected cases. While I have not seen any, I am not optimistic that an existing BEEP Core C++ library would satisfy Squid performance needs. In fact, I do not see any available open/free BEEP library in C++ on beepcore.org. For reference, a permaBEEP library has about 30,000 lines of Java code. I suspect that a decent native BEEP implementation in Squid would be 7,000 lines or less (without encryption support). > I agree and never said that BEEP is not efficient. I am not > concerned about our own implementation although it will probably be > somehow tricky to have an optimized XML parser for OCP and still > passing the compliance test that probably/hopefully The Measurement > Factory will come up with ;-) You can always take the lazy approach: an optimized XML parser for simple/canonical/expected cases and a slow XML library for anything else. The optimized parser would just have to be smart enough to know when its input is not a "simple/canonical/expected" case. > But evangelising others that this protocol is definitly the one they > should use or migrate to, this task could be a little harder to me. > That's my concern. I agree. I wonder how we should decide which way to proceed. What is better: - best fit: a simpler, compact, domain-specific transport that we have to write (OCPTRAN), increasing OCP adoption chances - fast result: a more complex, larger, general-purpose transport that we can reuse with some effort and loss of elegance (BEEP), decreasing OCP adoption chances I have a feeling that if "fast result" is the correct choice here, then we should just polish ICAP instead of doing OCP. On the other hand, if "best fit" is the way to go, then I am worried about documenting security negotiations (something BEEP already has). Alex. >> 1 An OCP/BEEP implementation would parse simple, >> short XML fragments most of the time. >> >> 2 To be compliant, an OCP/BEEP implementation would >> have to be able to parse arbitrary XML, including >> malicious XML. >> >> 3 In 7 years, virtually every OCP/* agent will support XML >> for reasons unrelated to transport; that support may not >> be efficient (e.g., parsing of configuration files or >> generating logs). >> >> 4 It is possible to optimize parsing of simple, >> short XML fragments with known parsing goal >> (e.g., just to find the profile URIs and ignore >> everything else). >> >> 5 It is possible to optimize generation of simple, >> short XML fragments. >> >> 6 It is very tempting to use XML for OCP negotiations >> and other, mostly performance-unrelated OCP tasks _if_ >> XML has to be supported for transport reasons anyway. >> >> 7 The use of XML will initially alienate a noticeable >> fraction of the existing ICAP community >> >> Does anybody disagree with any of the above assertions? From owner-ietf-openproxy@mail.imc.org Wed May 7 13:29:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09223 for ; Wed, 7 May 2003 13:29:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSlI-00038w-00 for opes-archive@ietf.org; Wed, 07 May 2003 13:31:24 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DSlH-00038r-00 for opes-archive@ietf.org; Wed, 07 May 2003 13:31:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47HIki2089292 for ; Wed, 7 May 2003 10:18:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47HIknf089291 for ietf-openproxy-bks; Wed, 7 May 2003 10:18:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com ([209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47HIii2089251 for ; Wed, 7 May 2003 10:18:44 -0700 (PDT) (envelope-from info@utel.net) Received: from f02m-4-134.d1.club-internet.fr ([212.194.15.134] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 19DSW7-00070d-00; Wed, 07 May 2003 10:15:49 -0700 Message-Id: <5.2.0.9.0.20030507183512.02af82a0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 07 May 2003 18:44:11 +0200 To: "Martin Stecher" , "Alex Rousskov" , "OPES Group" From: jfcm Subject: RE: AW: Using XML in OCP transport In-Reply-To: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I set-up my credibility filter to the support of DNS value added services. Obviously XML does not fit the job. There may be different support however. But was it expected is a lean, simple, stuff, robust and secure. Most of the initial aplications will be security. Where the flow will be authorised to go across, or will be trown away. Then it will probably be URL conversion (payment gateways could use that). jfc At 10:21 07/05/03, Martin Stecher wrote: > > > > Would it be fair to conclude, then, that your primary reason > > for avoiding XML in OCP is assertion #7 (the use of XML will initially > > alienate a noticeable fraction of the existing ICAP community)? > >My concern is that OCP will not be successful, if implementors don't like >it or find it too complicated or too much work to implement. > >So yes, my primary reason is #7. But regarding new potential implementors >it is more an issue of assertions #2 and maybe #6, meaning that an OCP >implementation which takes it serious needs fully compliant XML support. > >For example: ICAP support in the Squid proxy added less than 1500 lines of >code. Any idea what it will take to get OCP/BEEP into Squid? As far as I >know there is no XML support in Squid yet. > > > > > My reasoning is that if all of the performance-related assertions > > below are true, then there is no performance problem with XML in OCP > > context: all performance problems can be solved by practical, > > real-world engineering. Such efforts are virtually always required to > > support any new protocol efficiently anyway. If there are no > > performance problems, then (based on you past postings), I assume your > > primary concern is migration of existing ICAP community (i.e., > > assertion #7). Is my reasoning correct? > >I agree and never said that BEEP is not efficient. >I am not concerned about our own implementation although it will probably >be somehow tricky to have an optimized XML parser for OCP and still >passing the compliance test that probably/hopefully The Measurement >Factory will come up with ;-) > >But evangelising others that this protocol is definitly the one they >should use or migrate to, this task could be a little harder to me. That's >my concern. > >Regards >Martin > > > > > > Thank you, > > > > Alex. > > > > > > > > 1 An OCP/BEEP implementation would parse simple, > > > > short XML fragments most of the time. > > > > > > > > 2 To be compliant, an OCP/BEEP implementation would > > > > have to be able to parse arbitrary XML, including > > > > malicious XML. > > > > > > > > 3 In 7 years, virtually every OCP/* agent will support XML > > > > for reasons unrelated to transport; that support may not > > > > be efficient (e.g., parsing of configuration files or > > > > generating logs). > > > > > > > > 4 It is possible to optimize parsing of simple, > > > > short XML fragments with known parsing goal > > > > (e.g., just to find the profile URIs and ignore > > > > everything else). > > > > > > > > 5 It is possible to optimize generation of simple, > > > > short XML fragments. > > > > > > > > 6 It is very tempting to use XML for OCP negotiations > > > > and other, mostly performance-unrelated OCP tasks _if_ > > > > XML has to be supported for transport reasons anyway. > > > > > > > > 7 The use of XML will initially alienate a noticeable > > > > fraction of the existing ICAP community > > > > > > > > Does anybody disagree with any of the above assertions? > > > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.474 / Virus Database: 272 - Release Date: 18/04/03 From owner-ietf-openproxy@mail.imc.org Wed May 7 13:31:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09314 for ; Wed, 7 May 2003 13:31:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSn4-00039c-00 for opes-archive@ietf.org; Wed, 07 May 2003 13:33:14 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DSn3-00039Z-00 for opes-archive@ietf.org; Wed, 07 May 2003 13:33:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47HOEi2089440 for ; Wed, 7 May 2003 10:24:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47HOEaH089439 for ietf-openproxy-bks; Wed, 7 May 2003 10:24:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47HODi2089434 for ; Wed, 7 May 2003 10:24:13 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47HOEHa037103 for ; Wed, 7 May 2003 13:24:14 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47HO5Uf004983 for ; Wed, 7 May 2003 13:24:07 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47HO3Q4019906 for ; Wed, 7 May 2003 13:24:04 -0400 (EDT) Message-ID: <3EB94169.1000607@mhof.com> Date: Wed, 07 May 2003 13:24:57 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: AW: Using XML in OCP transport References: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > I agree. I wonder how we should decide which way to proceed. What is > better: > > - best fit: a simpler, compact, domain-specific transport that > we have to write (OCPTRAN), increasing OCP adoption chances > > - fast result: a more complex, larger, general-purpose transport > that we can reuse with some effort and loss of elegance (BEEP), > decreasing OCP adoption chances It's also about what can be done with the resources we currently have. Who would committ to agressively move a new transport forward, without slowing down work on the OPES challenges that are at our core. > I have a feeling that if "fast result" is the correct choice here, > then we should just polish ICAP instead of doing OCP. On the other > hand, if "best fit" is the way to go, then I am worried about > documenting security negotiations (something BEEP already has). What would we loose by "polishing ICAP instead of doing OCP" (over BEEP)? It seems that most folks thought the expected benefits would justify this approach. -Markus From owner-ietf-openproxy@mail.imc.org Wed May 7 13:31:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09332 for ; Wed, 7 May 2003 13:31:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSni-0003A2-00 for opes-archive@ietf.org; Wed, 07 May 2003 13:33:54 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DSnh-00039y-00 for opes-archive@ietf.org; Wed, 07 May 2003 13:33:53 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47HPPi2089479 for ; Wed, 7 May 2003 10:25:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47HPP4m089478 for ietf-openproxy-bks; Wed, 7 May 2003 10:25:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47HPNi2089471 for ; Wed, 7 May 2003 10:25:24 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h47HPP2R042383; Wed, 7 May 2003 11:25:25 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h47HPPbM042382; Wed, 7 May 2003 11:25:25 -0600 (MDT) (envelope-from rousskov) Date: Wed, 7 May 2003 11:25:25 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: RE: AW: Using XML in OCP transport In-Reply-To: <5.2.0.9.0.20030507183512.02af82a0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030507183512.02af82a0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 7 May 2003, jfcm wrote: > I set-up my credibility filter to the support of DNS value added > services. Obviously XML does not fit the job. Why not? If XML is only used for BEEP channel management and OCP is optimized to reuse existing session channles, then I do not see how XML [performance] prevents OCP from adapting DNS. Can you clarify? > There may be different support however. But was it expected is a > lean, simple, stuff, robust and secure. Most of the initial > aplications will be security. Where the flow will be authorised to > go across, or will be trown away. Then it will probably be URL > conversion (payment gateways could use that). How does limited use of XML in OCP prevent the above adaptations? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed May 7 15:29:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14430 for ; Wed, 7 May 2003 15:29:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DUdK-00042R-00 for opes-archive@ietf.org; Wed, 07 May 2003 15:31:18 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DUdJ-00042O-00 for opes-archive@ietf.org; Wed, 07 May 2003 15:31:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47JGEi2096755 for ; Wed, 7 May 2003 12:16:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47JGELh096754 for ietf-openproxy-bks; Wed, 7 May 2003 12:16:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47JGCi2096749 for ; Wed, 7 May 2003 12:16:12 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h47JGE2R046095; Wed, 7 May 2003 13:16:14 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h47JGEeY046094; Wed, 7 May 2003 13:16:14 -0600 (MDT) (envelope-from rousskov) Date: Wed, 7 May 2003 13:16:14 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: AW: Using XML in OCP transport In-Reply-To: <3EB94169.1000607@mhof.com> Message-ID: References: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> <3EB94169.1000607@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 7 May 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > I agree. I wonder how we should decide which way to proceed. What is > > better: > > > > - best fit: a simpler, compact, domain-specific transport that > > we have to write (OCPTRAN), increasing OCP adoption chances > > > > - fast result: a more complex, larger, general-purpose transport > > that we can reuse with some effort and loss of elegance (BEEP), > > decreasing OCP adoption chances > > It's also about what can be done with the resources we currently > have. Who would committ to agressively move a new transport > forward, without slowing down work on the OPES challenges that are > at our core. I do not think it would be a lot of work to define OCPTRAN because it will be integrated with OCP and will not be a stand-alone general-purpose transport protocol like BEEP. We can probable assume TCP as low-level transport and make many other simplifying, domain-specific assumptions as well. As we discussed before, it is not the amount of work to build OCPTRAN that pauses us, it is our desire to reuse things defined on top of or for BEEP Core (such as security negotiations). > > I have a feeling that if "fast result" is the correct choice here, > > then we should just polish ICAP instead of doing OCP. On the other > > hand, if "best fit" is the way to go, then I am worried about > > documenting security negotiations (something BEEP already has). > > What would we loose by "polishing ICAP instead of doing OCP" (over > BEEP)? It seems that most folks thought the expected benefits would > justify this approach. The original motivation to build OCP was to provide an application agnostic protocol (ICAP is HTTP-specific) with several key features missing from ICAP (e.g., multiple adapted response generation or copying optimizations). We cannot just "polish" ICAP to get most of those new things supported; we would have to make major changes, which is what OCP is supposed to do. If we do not use BEEP, but still do OCP, we can make messages look similar to ICAP ones. OCP can be a new protocol (with all the desired features) that just has ICAP-looking messages. Or, to be more accurate, messages that look more like ICAP/MIME than like BEEP/XML. Please note that I am not casting my vote here, just documenting and clarifying available options: - "polish" ICAP (e.g., document encryption) [ call it ICAP/1.1? ] - write OCP on top of TCP [ call it ICAP/2.0? ] - write OCP on top of BEEP [ call it OCP/BEEP ] Alex. From owner-ietf-openproxy@mail.imc.org Wed May 7 17:02:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17411 for ; Wed, 7 May 2003 17:02:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DW5U-0004jH-00 for opes-archive@ietf.org; Wed, 07 May 2003 17:04:28 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DW5T-0004jE-00 for opes-archive@ietf.org; Wed, 07 May 2003 17:04:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47Kpei2000745 for ; Wed, 7 May 2003 13:51:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47KpeiH000744 for ietf-openproxy-bks; Wed, 7 May 2003 13:51:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47Kpai2000739 for ; Wed, 7 May 2003 13:51:39 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47KpcHa040000 for ; Wed, 7 May 2003 16:51:38 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47KpVUf029982 for ; Wed, 7 May 2003 16:51:32 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h47KpVQ4029768 for ; Wed, 7 May 2003 16:51:31 -0400 (EDT) Message-ID: <3EB9720B.9050408@mhof.com> Date: Wed, 07 May 2003 16:52:27 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: AW: Using XML in OCP transport References: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> <3EB94169.1000607@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > As we discussed before, it is not the amount of work to build OCPTRAN > that pauses us, it is our desire to reuse things defined on top of or > for BEEP Core (such as security negotiations). And if we don't reuse these things, we've to re-invent them again, which adds to the amount of work... More important, however, is that we can rely on established solutions and don't have to worry about many things, including the security negotiations you mentioned. > The original motivation to build OCP was to provide an application > agnostic protocol (ICAP is HTTP-specific) with several key features > missing from ICAP (e.g., multiple adapted response generation or > copying optimizations). We cannot just "polish" ICAP to get most of > those new things supported; we would have to make major changes, which > is what OCP is supposed to do. Absolutely, this is the "benefit" I was referring to. > If we do not use BEEP, but still do OCP, we can make messages look > similar to ICAP ones. OCP can be a new protocol (with all the desired > features) that just has ICAP-looking messages. Or, to be more > accurate, messages that look more like ICAP/MIME than like BEEP/XML. Sure, that's an option, but we would than have to re-define all these things that something like BEEP already offers. > Please note that I am not casting my vote here, just documenting and > clarifying available options: > > - "polish" ICAP (e.g., document encryption) [ call it ICAP/1.1? ] > - write OCP on top of TCP [ call it ICAP/2.0? ] > - write OCP on top of BEEP [ call it OCP/BEEP ] Understood, it's appreciated! And we need to get closure on that one to move on. Anyone else a strong opinion? -Markus From owner-ietf-openproxy@mail.imc.org Wed May 7 19:26:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23324 for ; Wed, 7 May 2003 19:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DYKV-0005wZ-00 for opes-archive@ietf.org; Wed, 07 May 2003 19:28:07 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DYKU-0005wW-00 for opes-archive@ietf.org; Wed, 07 May 2003 19:28:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47NEhi2006229 for ; Wed, 7 May 2003 16:14:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47NEhCW006228 for ietf-openproxy-bks; Wed, 7 May 2003 16:14:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com ([209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47NEgi2006180 for ; Wed, 7 May 2003 16:14:42 -0700 (PDT) (envelope-from info@utel.net) Received: from f02m-10-171.d1.club-internet.fr ([212.194.21.171] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 19DY6J-00024E-00 for ietf-openproxy@imc.org; Wed, 07 May 2003 16:13:28 -0700 Message-Id: <5.2.0.9.0.20030508002858.0300e0d0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 08 May 2003 00:52:05 +0200 To: OPES Group From: jfcm Subject: Re: AW: Using XML in OCP transport In-Reply-To: <3EB9720B.9050408@mhof.com> References: <72992B39BBD9294BB636A960E89AE02EF54CEE@hermes.webwasher.com> <3EB94169.1000607@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 22:52 07/05/03, Markus Hofmann wrote: >>Please note that I am not casting my vote here, just documenting and >>clarifying available options: >> - "polish" ICAP (e.g., document encryption) [ call it ICAP/1.1? ] >> - write OCP on top of TCP [ call it ICAP/2.0? ] >> - write OCP on top of BEEP [ call it OCP/BEEP ] > >Understood, it's appreciated! And we need to get closure on that one to >move on. Anyone else a strong opinion? I fully agree that these are the options. (except that I would also consider on top of IP). I suggest that now this is clear, I suppose, to everyone, we go a step further and try to quantify the resulting qualities (there are not con and pros, just how it will be) of each solutions for a decision grid. The will permit to objectively list which applications best benefit from each approach, in which model context. I suppose IAB will ask that kind of documentation to support our choice? If we see and document that several solutions are in real demand, I have nothing against an OPES family of protocols. As you know I think OPES are just the begining of a total revamp the Internet access concept into an internet (ONES) service concept. jfc From owner-ietf-openproxy@mail.imc.org Wed May 7 19:26:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23341 for ; Wed, 7 May 2003 19:26:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DYKn-0005wf-00 for opes-archive@ietf.org; Wed, 07 May 2003 19:28:26 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DYKn-0005wc-00 for opes-archive@ietf.org; Wed, 07 May 2003 19:28:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47NEgi2006218 for ; Wed, 7 May 2003 16:14:42 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47NEf7J006217 for ietf-openproxy-bks; Wed, 7 May 2003 16:14:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com ([209.124.80.2]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47NEei2006179 for ; Wed, 7 May 2003 16:14:40 -0700 (PDT) (envelope-from info@utel.net) Received: from f02m-10-171.d1.club-internet.fr ([212.194.21.171] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 19DY6H-00024E-00 for ietf-openproxy@imc.org; Wed, 07 May 2003 16:13:25 -0700 Message-Id: <5.2.0.9.0.20030508000639.0300e340@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 08 May 2003 00:25:12 +0200 To: ietf-openproxy@imc.org From: jfcm Subject: RE: AW: Using XML in OCP transport In-Reply-To: References: <5.2.0.9.0.20030507183512.02af82a0@mail.utel.net> <5.2.0.9.0.20030507183512.02af82a0@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 19:25 07/05/03, Alex Rousskov said: >On Wed, 7 May 2003, jfcm wrote: > > I set-up my credibility filter to the support of DNS value added > > services. Obviously XML does not fit the job. > >Why not? If XML is only used for BEEP channel management and OCP is >optimized to reuse existing session channles, then I do not see how >XML [performance] prevents OCP from adapting DNS. Can you clarify? Sure. complexity, bandwidth, delay, size of the transported information. Security. I do not say any need for XML in the current needs I cover (DNS calls, acess redirection, IDNA, authorization of access). Just security precludes using an existing library without reviewing entirely. etc. > > There may be different support however. But was it expected is a > > lean, simple, stuff, robust and secure. Most of the initial > > aplications will be security. Where the flow will be authorised to > > go across, or will be trown away. Then it will probably be URL > > conversion (payment gateways could use that). > >How does limited use of XML in OCP prevent the above adaptations? What do you name limited use of XML? In the type of exchanges I consider (returning an ACE label for an IDN) can you quanty the overhead? The OPES procesor (your wording) filters the proposed DNs and send them to be rewriten to an OPES server (may be 10 to 15 characters). They are worked on for may possible services : - conversion in ACE label - conversion of an ITLD - permitted access - security check/taping/statistics (cf. Cisco current reponse to tapping legislations) - etc ... The new DN is returned. may be 10 to 25 characters so it may proceed toward the nameserver. Another application of interest: antispaming strategy. An OPES processor an MTA calls the sending UA to check the validity of the mailid (to check the origin) and permits the mail to proceeed. Sends the MailID (may be 10 to 50 chars) and receives a Y/N. Another application of interest a cookie server. I load the data there, not on the caller's machine. When a cookie is called my OPES processor captures the call and reroute to my cookie server. Very low, well established, non XML processes. I have nothing aganst XML when it brings a plus. I just say it isnot always the case. So it should not be mandatory. jfc From owner-ietf-openproxy@mail.imc.org Thu May 8 00:16:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29310 for ; Thu, 8 May 2003 00:16:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DcrY-0007XE-00 for opes-archive@ietf.org; Thu, 08 May 2003 00:18:32 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19DcrX-0007XB-00 for opes-archive@ietf.org; Thu, 08 May 2003 00:18:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48468i2018225 for ; Wed, 7 May 2003 21:06:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h484686q018224 for ietf-openproxy-bks; Wed, 7 May 2003 21:06:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48466i2018219 for ; Wed, 7 May 2003 21:06:06 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h484692R058684; Wed, 7 May 2003 22:06:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h48469Fq058683; Wed, 7 May 2003 22:06:09 -0600 (MDT) (envelope-from rousskov) Date: Wed, 7 May 2003 22:06:09 -0600 (MDT) From: Alex Rousskov To: ietf-openproxy@imc.org Subject: RE: AW: Using XML in OCP transport In-Reply-To: <5.2.0.9.0.20030508000639.0300e340@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030507183512.02af82a0@mail.utel.net> <5.2.0.9.0.20030507183512.02af82a0@mail.utel.net> <5.2.0.9.0.20030508000639.0300e340@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 8 May 2003, jfcm wrote: > On 19:25 07/05/03, Alex Rousskov said: > >On Wed, 7 May 2003, jfcm wrote: > > > I set-up my credibility filter to the support of DNS value added > > > services. Obviously XML does not fit the job. > > > >Why not? If XML is only used for BEEP channel management and OCP is > >optimized to reuse existing session channles, then I do not see how > >XML [performance] prevents OCP from adapting DNS. Can you clarify? > > Sure. > complexity, bandwidth, delay, size of the transported information. > Security. I do not say any need for XML in the current needs I cover > (DNS calls, acess redirection, IDNA, authorization of access). XML messages for BEEP channel management are not complex, are not significantly bigger than any other encoding we can come up with, and do not cause extra delays. Moreover, they are used relatively infrequently compared to OCP messages. I agree that our needs do not require XML. However, we may benefit from BEEP and BEEP requires limited use of XML. > Just security precludes using an existing library without reviewing > entirely. etc. I am not buying this argument because (a) you do not have to use any libraries you do not trust (b) are you also reviewing your compiler code and processor firmware entirely? > > > There may be different support however. But was it expected is a > > > lean, simple, stuff, robust and secure. Most of the initial > > > aplications will be security. Where the flow will be authorised to > > > go across, or will be trown away. Then it will probably be URL > > > conversion (payment gateways could use that). > > > >How does limited use of XML in OCP prevent the above adaptations? > > What do you name limited use of XML? BEEP channel management. I posted some examples and the BEEP RFC contains a lot more information, of course. Marshall has pointed out many times by now that mainstream BEEP exchanges do not have to use XML, they can use whatever MIME type we want, including new ones. > In the type of exchanges I consider (returning an ACE label for an > IDN) can you quanty the overhead? This type of exchange does not have to use XML at all as long as BEEP sessions and channels were established prior to the exchange (to handle many exchanges, presumably). We are working within a connection-oriented framework (for OCP, not necessarily for the application being adapted). > The OPES procesor (your wording) filters the proposed DNs and > send them to be rewriten to an OPES server (may be 10 to 15 > characters). They are worked on for may possible services : > - conversion in ACE label > - conversion of an ITLD > - permitted access > - security check/taping/statistics (cf. Cisco current reponse to > tapping legislations) > - etc ... > The new DN is returned. may be 10 to 25 characters so it > may proceed toward the nameserver. That's fine. OCP messages do not have to use XML. > Another application of interest: antispaming strategy. An OPES > processor an MTA calls the sending UA to check the validity of the > mailid (to check the origin) and permits the mail to proceeed. Sends > the MailID (may be 10 to 50 chars) and receives a Y/N. > > Another application of interest a cookie server. I load the data > there, not on the caller's machine. When a cookie is called my OPES > processor captures the call and reroute to my cookie server. Very > low, well established, non XML processes. > > I have nothing aganst XML when it brings a plus. I just say it > isnot always the case. So it should not be mandatory. And it is not, not for OCP messages. XML is only mandatory for BEEP channel management and, since we assume long-lived OCP connections, the overhead of channel establishment can be spread across many application messages being adapted. Alex. From owner-ietf-openproxy@mail.imc.org Thu May 8 00:34:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00186 for ; Thu, 8 May 2003 00:34:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dd8q-0007bx-00 for opes-archive@ietf.org; Thu, 08 May 2003 00:36:24 -0400 Received: from mail.proper.com ([208.184.76.45] helo=above.proper.com) by ietf-mx with esmtp (Exim 4.12) id 19Dd8p-0007bu-00 for opes-archive@ietf.org; Thu, 08 May 2003 00:36:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h484PMi2018692 for ; Wed, 7 May 2003 21:25:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h484PMBW018691 for ietf-openproxy-bks; Wed, 7 May 2003 21:25:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h484PLi2018686 for ; Wed, 7 May 2003 21:25:21 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h484PO2R059063 for ; Wed, 7 May 2003 22:25:24 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h484POcf059062; Wed, 7 May 2003 22:25:24 -0600 (MDT) (envelope-from rousskov) Date: Wed, 7 May 2003 22:25:24 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: AW: Using XML in OCP transport In-Reply-To: <5.2.0.9.0.20030508002858.0300e0d0@mail.utel.net> Message-ID: References: