At 01:09 AM 8/10/2001, Ian Cooper wrote:
At 02:31 8/7/2001 -0700, Michael W. Condry wrote:
Although our goals has not changed the languange
is changed to make clear that OPES is about devices that
will be IP endpoints.
Open Pluggable Endpoint Services (opes)
As I mentioned in the meeting, I don't believe that the change to
"endpoint" is useful. I think one could easily misinterpret "endpoint" to
be read "my laptop/desktop". Unless you're planning on considering such
points in the work of the group?
Actually, I am going to return to Edge. "Endpoint" vs. "Edge" is a rathole.
think specifications of what can be "Edge" is a charter items so the
other comment on "my laptop/desktop" is not an issue.
Web-based service engines are sometimes identified as "edge" servers,
which form an application-level overlay network on top of an IP network.
They are explicitly addressed at IP level and terminate a transport
connection in a normal way. Thus, they do not interfere with the
end-to-end principle in RFC 1958.
This is a weak attempt at addressing the concerns over "end-to-end",
though I agree it's very good to be explicit in identifying that the OPES
systems are explicitly addressed.
Its not a weak point at all. Following the concerns over "end-to-end" and the
explicit space of OPES we should discard web proxyies, the web, ... And
As mentioned previously, there are application level/content end-to-end
concerns over deploying such an architecture - inherent in an overlay
network environment. Please be aware of *that* end-to-end issue when
stating reference to RFC1958.
"concerns" are useless comment. How about explicit items so matters could
be made more specific in the charter and documents. Vague comments
are not worthwhile.
Web services are not transparent: They must be authorized by the
application endpoint (either the content requestor or the content
provider), corresponding to who requested the service. A key task for the
working group is to specify an appropriate authorization mechanism.
I hope others participating in this area were at the URP BOF on Wednesday
The iCAP protocol provides similar function for services operating on
iCAP encapsulated HTTP messages. The working group will evaluate the iCAP
protocol as one candidate for passing HTTP messages for remote services.
It may decide to extend or even not use the iCAP protocol without being
obliged to retain any level of compatibility with the current iCAP proposal.
I still think the inclusion of the above paragraph adds nothing to the
charter (and actually makes it weaker).
Michael W. Condry
Director, Network Edge Technology