Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-ietf-behave-turn-uri (Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed Standard]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Oct 22, 2009, at 3:05 PM, Marc Petit-Huguenin wrote:

...
With regard to complexity, that is most likely in the eye of the
beholder.  I would think this is more complex than other uses of
S-NAPTR. I don't know how one goes about judging these sort of things.
Perhaps it would be helpful to look at an S-NAPTR implementation.
VeriSign's SVN repository still hosts pysnaptr, which you can find here:
http://svn.verisignlabs.com/main/snaptr/pysnaptr/tags/RELEASE_0_1/pysnaptr

...
For comparison my own reference implementation in Java of the TURN URI parser and resolver is 364 lines long. This is without the RFC 3958 implementation, 255 lines long, and the RFC 2782 implementation which is 141 lines long. The URL
to this reference implementation is in Annex A.10 in the I-D.

Marc,

I suppose if I had been a little more caffeinated this morning, I would have also provided links to VeriSign's Java and Perl implementations of 3958:

http://svn.verisignlabs.com/main/snaptr/net_dns_snaptr/trunk/lib/Net/DNS/SNAPTR.pm
http://svn.verisignlabs.com/main/snaptr/jsnaptr/trunk/src/com/verisignlabs/jsnatpr/JSNaptr.java

Lines of code is certainly one measure of complexity, but that can be heavily influenced by the programming style and language used. Again, this is all subjective, but in my opinion it is complex. I think most of that is due to the nature of NAPTR and DNS itself and perhaps cannot be avoided. I hope this is helpful.

-andy
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]