The Sprint spec was issued under an NDA as a formal RFP. I know that
several member companies on this list received the RFP. It is not
publicly available for competitive advantage reasons.
Some hint of what is in it is publicly available in the form of white
papers written by me and my team. These are available for download
through http://developer.sprintpcs.com/ . You have to join but there is
no cost and it is spam free. The white papers focus on the applications,
it is not immediately obvious that an intermediation system is required
under-the-hood to enable it. These papers are also 1 year old. They
begin to look dated.
My successor at Sprint is Martin Geddes, who was previously one of my
staff. Martin is always happy to talk about this stuff and has spoken to
several of companies who are members on this list. I will be happy to
pass on his details if you send me a private request.
Cheers,
David
David J. Anderson
Direct 206.664.9610
e-mail dja(_at_)4thpass(_dot_)com
-----Original Message-----
From: Abbie Barbir [mailto:abbieb(_at_)nortelnetworks(_dot_)com]
Sent: Thursday, July 25, 2002 9:53 AM
To: David Anderson; ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: To chain or not to chain
david,
thanks, very good points.
can u give us the pointer to sprint specifications.
thanks
abbie
-----Original Message-----
From: David Anderson [mailto:dja(_at_)4thpass(_dot_)com]
Sent: Thursday, July 25, 2002 12:05 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: To chain or not to chain
Hi,
I've been lurking on this list for several months. I have no
idea what the protocol is for introducing myself and whether or not I'm
allowed to speak up - as my company is not a member of the OPES group.
However, until recently I worked at Sprint, where my team issued an RFP
for an "Intermediation" system earlier this year i.e. a customer
requirement for an open pluggable edge server. I know a lot about this
topic as my team at Sprint built a working prototype of such a system
and implemented micropayments and other intermediation functions. We
demoed this at the Sprint Developers Conference in Las Vegas, during
October 2001.
I have watched this debate about callout chaining for some time.
I would like to make several observations and identify what I believe to
be several underlying and unspoken assumptions in the group.
1.No one has ever mentioned whether or not chaining is a real
market requirement.
It seems to be assumed that the market does not know what it
wants or whether it needs this technology. It is being designed by
technologists. However, there does exist a marketing requirements
document from a large telco. Sprint published one.
2.Functional versus Procedural coupling
The argument around chaining can be abstracted down to whether
or not callouts can be loosely coupled and functionally cohesive, or
whether procedural coupling is required. This is the 30 year old debate
in software engineering about procedural versus functional
decomposition.
There appears to be an underlying assumption that the switching
cost of invoking a callout is high. If this were so, then procedural
coupling would produce a performance enhancement by reducing the number
of redundant switching calculations. However, if the switching cost of
invoking a callout is low, in comparison to the processing time of the
individual callout functions, then there is little performance
improvement to be achieved from procedural coupling i.e. chaining.
To decide whether chaining is worth the cost of the protocol
overhead and the need for the callout server, to act as an OPES server
(in order to chain), the group must decide whether the switching cost of
invoking an OPES callout from the flow of the network, is significant.
It would appear that determining whether or not this is significant
cannot be achieved until a first cut of the specification is agreed and
the performance can be determined.
Hence, it would seem too early to make a call on whether or not
chaining is worthwhile.
3.Functional versus Procedural design
Is chaining even needed? To understand this, we must evaluate
whether or not procedural designs will emerge. We must look to the uses
and the usage of an OPES system and decide whether chaining seems
likely.
For example, let's imagine the mainline network is http. We are
interested in switching http requests or responses for two reasons:
micropayments - pay per click, subscribe to a set or URLs e.g. New York
Times Today; automatic form fill - a la MS Passport without the
application layer interface, i.e. no need to re-write the URL with a
defined set of name value pairs for identity. Those are just two
examples. At the last count my team had 11 applications for an OPES
style system.
Now consider whether it is likely that we would switch on the
same URL for two different applications, i.e. is it likely that the same
URL which needs a micropayment challenge, would also require a form
fill?
The underlying assumption on this list is that it is too early
to second guess the market and the possible usage of OPES. Hence, the
specification should be as flexible as possible. However, flexibility
comes at a cost. It adds complexity, risk and time to market.
IMO, providing an OPES 1.0 spec which allows functional callout
is a major step forward. It might be better to take the option theory
approach and decide to keep your options open regarding chaining. There
is no guarantee that the market needs chaining. If later there is demand
then exercise your option and build it into a subsequent version of the
specification.
Regards,
David
......
David J. Anderson
Director of Engineering
::4thpass
83 S. King Street, Suite 100, Seattle, WA 98104
phone (206) 749 9070, ext 110
e-mail dja(_at_)4thpass(_dot_)com
-----Original Message-----
From: Abbie Barbir [mailto:abbieb(_at_)nortelnetworks(_dot_)com]
Sent: Thursday, July 25, 2002 7:52 AM
To: Markus Hofmann; Hilarie Orman, Purple Streak Development
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: Chaining of Callout Servers
good points so far,
I also think that chaining will also add difficulties on
tracing.
I could think of various scenarios where loops may occur in the
chanied callout servers due
to programming errors (or server failures).
On the otherhand, I could also see the benefits of chaining if
it is done right.
However, My personal opinion at this stage of the game is to
start simple with an eye on expansion, so basically let us start with no
chaining and keep this option open for later.
abbie