-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/12/2010 09:15 AM, Iñaki Baz Castillo wrote: > 2010/10/12 Marc Petit-Huguenin <[email protected]>: > >> No, I do not, quite the opposite in fact. But I really wish that SIP >> authors, >> either for proprietary or FOSS stack (and this apply in fact for all Internet >> protocols) really read and implement the RFCs, instead of cherry-picking what >> they like or not in them or - ultimate abomination - implement a standard by >> using the examples in them. How many stacks correctly implement the second >> paragraph of Section 18.1.1 of RFC 3261? Or RFC 3263 for that matter? > > Second paragraph of Section 18.1.1 of RFC 3261: > > ------------------------- > If a request is within 200 bytes of the path MTU, or if it is larger > than 1300 bytes and the path MTU is unknown, the request MUST be sent > using an RFC 2914 [43] congestion controlled transport protocol, such > as TCP. > ------------------------- > > IMHO this is an exotic specification. What about if the > proxy/registart has to route a long request to a user registered in a > UDP location? should the proxy try TCP? to which port? what about NAT? > So this is a so exotic "feature" that I strongly understand everybody > ignores it [*]. > > Same occurs in section 23 (S/MIME). Who the hell does implement this > useless feature designed to work in a happy world in which everybody > has his own trusted certificate? Anyhow RFC writers MUST include > stupid stuff (like S/MIME) in order their drafts to be approved by the > IETF. So, which kind of ugly game is it? should the specifications be > robust and easy to implement (like XMPP)? or should they fulfill > useless requeriments? > > [*] However Twinkle softphone implements it :)
QED > > > >> My point is: Implementers have a duty to implement the standard strictly as >> it >> is written. If they disagree or do not understand some part of it, there is >> no >> shortage of people that will explain things. If you still disagree or do not >> understand, write an Internet-Draft to fix it or to explain it. That's the >> right thing to do. > > Sure, but having more "user-friendly" specifications would help. :) Yes. And this is where implementers can really help, by participating in the discussion of the specifications. This is what I did for TURN - I implemented it from scratch 3 times during the long gestation of the I-D, and continuously reported issues. I certainly did not had everything I wanted in the final spec but I think that this is at least an implementable standard. And for the parts that did not went in the spec, I pushed them separately (see RFC 5928). - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky0kRkACgkQ9RoMZyVa61dmIgCeO3MlkuVnPO28UxHWC+AHXIAk AFEAn3aa6Y+r4bdX3HePh8uEgzk+SypP =ujs7 -----END PGP SIGNATURE----- _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
