On Thu, Nov 13, 2008 at 12:19 PM, Alex Balashov <[EMAIL PROTECTED]>wrote:
> 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. > What is Asterisk designed to be? A PBX. (yes that is a period) > > -- 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 > Yes, if I want to read a book, I do, this is a mailing list so I really didn't read much of what you said above, if you cannot get to the point in a few lines within a few paragraphs, you are wasting my time.... Not sure why you feel like you need to correct me so badly or Who I have attacked? I take exception to this statement. That is the only clarification I request from you, no book needed. Sounds personal, let it go, it failed, but I washed my hands of it long ago..... -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype)
_______________________________________________ -- 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