[Top] [All Lists]

Re: Charter updates, changes, etc.

2001-03-28 06:17:50


I've been following this list (passively) since last year.

I was just wondering if anyone has brought-up the issue of copyright
when content is modified, and the callout-server providing a rights-checking
service in conjunction with content modification. This would imply that
the content itself would have to carry additional information/bits
indicating which parts were subject to copyright, and thus should not
be modified.

My first reaction was that the callout servers would be a suitable
place to do all these rights-related functions.  Does the ExtProxy/OPES folks
here think this way, or would such callout servers be too complicated.

Does iCAP allow for modification of more complex stuff (eg. MPEG4 streams)?

Any comments,


At 3/26/01||01:49 PM, you wrote:
I've attempted to combine both Michael's and Hilarie's comments together below.

At 08:13 3/23/2001 -0800, Ian Cooper wrote:
At 07:21 3/23/2001 -0800, Michael W. Condry wrote:
Description of Working Group:

The Open Pluggable Edge Service (OPES) working group primary
task is to define a protocol to be used to extend
participating transit intermediaries to incorporate services
executed on application data transported by HTTP and
possibly RTP protocol suite.  The protocol provides a framework for
integrating a wide range of services into arbitrary
intermediaries. Intermediaries may employ either local or
remote ("callout") servers to perform a service, and as a
result, the data may be diverted temporarily over a closed
loop pathway different from the transit pathway.

The value of the "remote" or "callout" server is that it can be provisioned
elsewhere on the network, not in the transit pathway.

Michael wrote:
I thought that was clear it was out of the transit pathway. What's confusing?

It's not confusing, and the paragraph wasn't meant to stand on its own.

I may be projecting my own thoughts, but in the meeting we said that SMTP
should be out of scope, since services such as virus checking are typically
provided by the introduction of another SMTP relay (and this notion in SMTP is
well established).  Service introduction in HTTP could also be provisioned
within a proxy on the transit path.  The use of a callout server "only" seems
to gain you some control over possible loops and the avoidance of complication
of transit pathways.

Ian, yes SMTP was out of scope. Just how do you read it in?

[Yes, we did say that SMTP was out of scope, but the charter
seems to be fairly clear on that point, does it not?]

Yes, the proposed charter made the scope clear.  (That doesn't necessarily mean
that the scope of the proposed charter is "valid" until the list comes to
consensus.  I wanted to provide those folks who didn't manage to attend the
meeting some additional context since this charter was being rushed to last
call before the minutes of the meeting were available anywhere.)

I probably didn't do a particularly good job of explaining myself.

My understanding of the specific exclusion of SMTP was that (to paraphrase) "to
provide services in that model, you simply pass things through another SMTP
relay".  Fine.  You *could* allow the callout mechanism to include SMTP within
scope, though it seems the group doesn't want that.  Fine.  (Why?)

I think my point is that the initial text wasn't particularly clear that the
whole point of the service provision model in OPES is built around the notion
of a callout server, and the control protocols of OPES devices.

"Intermediaries may employ either local or
remote ("callout") servers to perform a service, and as a
result, the data may be diverted temporarily over a closed
loop pathway different from the transit pathway."

I know my issues are with network architecture (for the large part), but if
you're using the transit pathway to get the services, you could just as easily
provide the services on an upstream within-transit-pathway proxy and do without
the callout.  And yet that's explicitly out of scope.  Perhaps you're trying to
cover too many issues in a short amount of text?

I'd also suggest removing the parentheses around "callout", since that - to me
- suggests that it's only a callout in the case of a remote server.  And if
it's not a callout on a local server (what's the difference between the OPES
intermediary and the "local server?) then what is it?

Intermediary services provided in this way are not
transparent: Either the content requestor or provider will
be aware that a transformation has been performed.

Did we remove the case where the access provider is the one controlling the

I misread this part of the text.  My bad.

As part of the development of this protocol the working
group will produce an analysis of the security implications
of this architecture.

I'm not too sure how I see this as being different to the security
considerations part of any protocol documents.

I think that Hilarie's point is quit interesting and worth discussing.

I don't disagree with you.  I was commenting on the *context* of where the
discussion would be reported, that's all.

[The WG needs to discuss this; my understanding of the
charter is that the 'integrity' of the content and authorization
of services based on roles and identities and signatures is
all part and parcel of the 'security considerations' in this case.
Also, the assurance of the 'awareness' of the authorizing
parties for each (?) service action.]

My point was that the wording of the paragraph strongly suggested that the
group will produce a security implications *document*.  Of course a WG would
have to discuss security consideration - you're unlikely to get very far with
IESG without it.  And that's my point.  I guess there's little harm in
including the above wording, but it seems rather redundant?

(That said, 2186/7 cover this stuff separately, so there probably isn't too
much of an issue.)

The iCAP protocol already provides similar functionality and
this working group may elect to use iCAP as a starting point
for its work. However, the working group is not obliged to
retain any level of compatibility with iCAP.

This paragraph seems redundant.  It seems to make more sense to have iCAP as a
draft for consideration within the group, but I'm not sure it belongs within
the charter description text.

lets see what other's think.

Hilarie: (former co-chair, you went and changed just to make it hard!)
[I agree]

That makes two of us :)

Jul 01:  iCAP Protocol document last call.

But you said you wouldn't be obliged to maintain compatibility with iCAP.

So either you're using the name to mean "something that doesn't look like iCAP
does at the moment" or you mean "we may recharter to change this goal".

[I read this as "being as you've got to start from ICAP, you might as well
ratify it as an existence proof of there being at least one acceptable
protocol.  You can later decide that you've got requirements that
supercede ICAP, but ICAP will still be useful for some solutions."]

Whoa! Who said we *have* to start from iCAP?

I assume, at the least, that the plan is to take iCAP to Informational.

Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.

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