Steve Totaro wrote: > Alex is going to cling to to the RFC as if it were the gospel, and not > look at what would essentially be a "good thing".
The RFC is not "the gospel," but nor is it just a "request for comment," historical nomenclature aside. It is the de facto standard for the implementation of the protocol, the product of IETF working groups, various standards bodies, and private and academic industry consortia. It is essential for interoperability and is the source of the justification for the appeal to "sameness" in the claim that two elements or services speak the "same" protocol. Inconsistencies, omissions, or deviations from the standard in implementations do not materially undermine this point. Nothing is perfect, including the RFC itself, which is replete with ambiguities open to interpretation and disagreements about those interpretations. However, it does provide the anchor for essential adherence, especially when it comes to points that are spelled out clearly (i.e. the basic purpose and function of registration and contact bindings) as opposed to more marginal scenarios. Do I really have to explain why it is important to follow the RFC when implementing an IETF protocol? One thing you need to appreciate is that when you are recommending changes to default settings, you are engaging in a kind of standards work. That's because the potential implications apply to everyone. In light of that, I find it bizarre that you solicit "input" on your suggestion but then proceed to personally attack those who disagree, especially with arguments proceeding from standards. > Making many NAT questions drop off IRC and and the list. Making > administration and system deployments "Just Work". More precisely, make administration and system deployments that are readily conceptualised in _your_ imagination and experience "just work." The behaviour you are suggesting would break any number of other scenarios common in the engineering of VoIP service delivery platforms. You are making a claim from the standpoint of someone who goes around installing phones that transact directly with an Asterisk PBX, and you are attempting to universalise your use case as though it were cosmologically significant. That is just one of the many scenarios in which SIP is used, and certainly only one of the manifold applications of Asterisk's SIP stack, in theory and in practice. What is important to phone installers isn't what matters to others. When recommending changes to standard behaviour, you have to argue in reasonable terms and contend with valid arguments rather than just dismissing them. I suppose we should be grateful that standards bodies for the most part consist of people considerably more judicious and insightful than that. The RFC provides an architectural model for how SIP works, and if you're going to suggest changes to an implementation of that model, it's important to understand what the model actually is on a level of abstraction that may considerably surpass your narrowminded assumptions based on your own use. The world of SIP entails considerably more complexity than phones and PBXs. -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users