There are two types of extensibility * Functionality * Mechanism
The type of extensibility that adds value is functionality. Extensibility for additional mechanisms rarely adds value and more usually causes more problems than it solves. For example, there are 30 plus mechanisms defined to allow username password authentication via SASL. That is very interesting for the academics but worse than useless for actual users. At one point IPSEC had a baroque negotiation mechanism for negotiating the key negotiation mechanism. The process of writing standards is removing flexibility. Ideally you remove flexibility that is not necessary for functionality. The other aspect of extension mechanisms to consider is where the best place to put the flexibility is. When the Internet design was started a core design goal was to enable it to be used for more than just one application. The telephone system has the intelligence in the core of the network and the ends are simple. The original internet design was the other way round, complexity at the ends and the core as simple as possible. Computer systems have proliferated since and there are now several billion endpoint devices. So for some types of extension it is best to work at the end, for others it is best to work at the edge, the point where networks join to the inter-network. The other major change in the Internet architecture is that Internet endpoints are now services identified by DNS names and not IP addresses and ports. Alternative naming schemes only add mechanism, they do not add functionality. On Tue, May 11, 2010 at 8:53 AM, Dave CROCKER <[email protected]> wrote: > > > On 5/10/2010 10:07 PM, SitG Admin wrote: >>> >>> I'm not understanding what you are describing. >> >> I've failed to answer your question, then - sorry I couldn't be of more >> help here. >> >> I'm still in favor of OpenID not relying on the singularly centralized >> DNS, since OpenID can only be as "decentralized" as its *most* >> centralized component. (Unless there are alternatives which can replace > > Then you had better also design it not to use IP or TCP or any other > Internet Standard. > > In other words, the goal you've stated is not going to work, if you are > diligent and consistent in pursuing it. > > As for 'centralized', perhaps you might like to review the design and > operation of the DNS in a bit deeper detail. Both registration and > operation of the DNS are highly decentralized. What is centralized is > control of the contents of the root of the tree (but not even operation of > it.) It is, in fact, the largest operational distributed service in the > world. > > >>> I'm quite sure you are describing a non-existent capability. >> >> I'm quite sure that *OpenID v.Next* is still non-existent ;p > > Exactly. Designing one new thing to rely on another, unspecified new thing > doesn't work. There's plenty of experience with this problem. > > >>> Making current designs attempt to cover unspecified hypothetical >>> extensions is typically not successful in these efforts. >> >> It's the chicken-and-egg dilemma: forward-compatibility. See: >> http://lists.openid.net/pipermail/openid-general/2009-November/019470.html >> OpenID is an authentication encapsulation protocol, *intended* to be >> extensible. Does it actively *hamper* OpenID to remain open to the >> possibility of future developments in an area of interest? > > Extensibility is fine. It has limits. That's not a theoretical statement. > > Please take a look at: > > <http://bbiw.net/ietf/ietf-stds.html#StdWay30> > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- Website: http://hallambaker.com/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
