ietf-openproxy
[Top] [All Lists]

Some attempts at clarification

2003-04-09 23:40:48

Recently several of us spent a couple of hours in a phone call trying
to clarify some issues that have come up on the mailing list.  We'd
like to share our "findings", such as there are, with the hope that
they will help the WG reach consensus.  In some cases we were only
able to clarify question or summarize what has already been discussed
on the mailing list.  In all cases, the final resolution will
come from the discussion on this mailing list.  Feel free to discuss,
dispute, rebutt, defend, or embrace anything presented here.  All
resolutions will be by consensus of the WG on the mailing list.

Hilarie

=================================

Message definitions and relating messages to connections

OCP has no particular requirements about how messages from the flow
proxied by an OPES processor is carried or represented in OCP
messages.  The messages in a proxied flow can be messages from or to a
data consumer and messages from or to a data provider; Alex suggested
that messages from the OPES processor to either endpoint be called
"application output messages" and messages from either endpoint to the
OPES processor be called "application input messages".  The Policy
Requirements draft has four processing points identifying these
message sending/receiving points (figure 2) as 1, 2, 3, and 4 (input
from consumer, output to provider, input from provider, output to
consumer).  Would rewording to refer to these processing points, rather than
naming messages, be helpful?

OCP has a message type called "application message"; its purpose is to
allow the callout server to send several modified messages
(e.g. different versions of the same content) as its part of one
callout transaction.  Hilarie objected to this on the grounds of
complexity, suggesting that if it is needed it could be done with
application-specific metadata.

The ensuing discussion yielded the assertion that OCP could not be
implemented without a binding to an application protocol.  One
solution is for OCP be specified as a core protocol and that separate
documents could be produced with the OCP-HTTP, OCP-SMTP, OCP-FTP,
etc. bindings.  The current draft would be called the "OCP core"
protocol, with no application-specific information.  The OCP-HTTP
document would need attention as soon as the protocol elements are
firm.

There might be protocol independent services, such as mime part
transformation, because mime parts can occur in several different
application protocols.  One solution would define a new application
protocol binding for OCP, such as OCP-MIMEPARTS.  Are there other
solutions?

OCP can be described with a layering model, and the draft might
describe it as:
OCP-Application-Messages 
OCP-Transactions
OCP-Connections
OCP-Transport Binding
Layer 4 Transport
IP

Loop Shortcuts

Abbie said that he wanted to allow the callout server to shortcut the
loop used by OCP and send modified content directly to the intended
recipient on the proxied dataflow.  If proxied application protocol
allows redirection, then the OPES processor can send it a redirection
message that results in it communicating directly with the machine
running callout services, but the callout server must then run
application server code.  Should these kinds of shortcuts be
documented in OCP or any of our other documents, or can we just let it
stand as "obvious to those versed in the state of the art"?

Negotiation

Capability negotiation is needed on a per transaction basis, not just
on a per connection basis.  Transactions with similar capability
requirements can be grouped usefully onto a single connection.  We
need to make sure this is compatible with privacy and security
requirements; we have to revisit this wrt to the requirements and what
can be done with IPSec and TLS.

Tracing

There has been a lot of discussion of notification vis-a-vis tracing.
Tracing can probably be best regarded as the proposed mechanism on
which to base notification.  

The major objection to defining out-of-band protocols for tracing or
notification is that the chance of adoption is low.  However, it
remains to be seen if we can develop mappings onto application
protocols that satisfy all the requirements.

Tracing is a requirement on an OPES processor, not the OCP protocol.
An important question is whether or not the OPES processor must be
aware of all the OPES services performed by a callout server.  It
might be, if the requirement is that the callout server perform ONLY
services explicitly requested by OPES processor, or it might not.  If
not, it should be able to ask the callout server to include such a
list as metadata on OCP Application Messages.  Oskar noted that the
callout server MIGHT want to include additional information that would
be useful, such as parameter settings used during execution of a
service.  Should this additional information be specified as
application-independent metadata in OCP Application Messages?

Should there be a way to request that the response to a proxied
message include tracing information identifying ALL OPES services
applied to it (to both the response and the reply)?  Given that it
would be impossible to require complete disclosure of services from an
entity with which you had no contractual agreement, this cannot be
fully enforced, but it would be OK for cases with such an agreement.
Is this sufficient to satisfy the notification requirement of the IAB?

Alex notes that an advantage of having tracing data added to all
messages going through an OPES processor is avoidance of any need to
signal which connections or transactions or messages were subject to
tracing.  This is a major simplification.

"Clarifiers"

Alex Rousskov
Abbie Barbir
Oskar Batuner
Reinaldo Penno
Martin Stecher
Hilarie Orman
Markus Hofmann
Marshall Rose

<Prev in Thread] Current Thread [Next in Thread>