At 11:21 6/27/2001 -0400, Lee Rafalow wrote:
Also, as one might expect, I share Jayanth's concern. I disagree with any
implication that icap is the answer. In my edits below I've made a few
changes in that paragraph to further
clarify the status of icap in the charter and I've changed the wording for
the deliverable from "icap" to "callout" protocol. But I can go with
Jayanth's suggestion to strike icap from the charter.
I'd also echo Lee's and Jayanth's concerns on this issue.
The proposed revised charter makes the paragraph on iCAP *redundant* in my
opinion.
From the latest revision:
Intermediaries may employ services executed either locally or on a remote
("callout") server. One task for this working group is the development of
callout protocols that enable the receiving callout service to either
receive encapsulated HTTP or RTP/RTSP messages or, through some other
mechanism, for the callout service to receive the application data
necessary to perform its services.
OK, so it's a task to look develop callouts. Why name one in particular
unless it already fits the puzzle? Especially since you then go on to say
that what-is-called-iCAP-now may not be in any way
what-we-call-iCAP-when-we're-done-with-it.
Of *course* the group will look at existing protocols. And if those are
deemed appropriate for re-use it should reference them. If they need to be
updated to make things fit, without breaking existing systems, then update
them. But what I see is folks saying "iCAP doesn't work/fit" *now*. If
that's the case don't mention it in the charter!
This group is constantly using the acronym "iCAP" to refer to "a callout
protocol we will develop". Please stop. Use another name. OCP (OPES
Callout Protocol) seems to work for the time being. If the thing that will
pop out of the group at the end of all this bears no resemblance to what we
call iCAP today, it only serves as a source of confusion to call it iCAP *now*.
*sigh*
</rant>
To end on a positive note, I definitely like the latest revision for the
most part - much clearer.