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

Marc Petit-Huguenin <petithug@acm.org> Thu, 22 October 2009 21:59 UTC

Return-Path: <petithug@acm.org>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1293A697F; Thu, 22 Oct 2009 14:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.159
X-Spam-Level:
X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u62bal+GvCjT; Thu, 22 Oct 2009 14:59:24 -0700 (PDT)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 61B4F3A6842; Thu, 22 Oct 2009 14:59:24 -0700 (PDT)
Received: by server.implementers.org (Postfix, from userid 1001) id BCDFA6C9852E; Thu, 22 Oct 2009 21:59:33 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id B5FEA6C98528; Thu, 22 Oct 2009 21:59:32 +0000 (UTC)
Message-ID: <4AE0D5C3.8010808@acm.org>
Date: Thu, 22 Oct 2009 14:59:31 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701)
MIME-Version: 1.0
To: Andrew Newton <andy@hxr.us>
References: <4AD7387A.7060901@ericsson.com> <6e04e83a0910151433y2007a015ia77a407e702a3841@mail.gmail.com> <4AD7AE35.7030701@petit-huguenin.org> <6e04e83a0910151809x522b1547ya48bcf6a2093ea01@mail.gmail.com> <4AD81911.4080809@acm.org> <6e04e83a0910161009r4ae93cd6j8063f117521d939f@mail.gmail.com> <E470E3F9-E3DE-414A-8A4B-6D0ABE589797@hxr.us> <4AE0AD11.3080307@acm.org> <277C1D22-695A-4D2A-A7A4-9CC96439AFEA@hxr.us>
In-Reply-To: <277C1D22-695A-4D2A-A7A4-9CC96439AFEA@hxr.us>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Ted Hardie <ted.ietf@gmail.com>, app-ads@tools.ietf.org, uri-review@ietf.org, ietf@ietf.org
Subject: Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-ietf-behave-turn-uri (Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed Standard]
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2009 21:59:25 -0000

Andrew Newton wrote:
> 
> 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.

Well, I do not think that the full complexity of NAPTR and SRV should be counted
when evaluating the implementation complexity of this I-D.  A TURN URI is used
by a TURN client, which is probably used in an ICE implementation which is
probably used in a SIP UAC.  A SIP UAC is probably implementing RFC 3263, which
means that NAPTR and SRV are already implemented.  So the real complexity is the
complexity of the TURN URI parser and the resolver as defined in the I-D and the
complexity of S-NAPTR (i.e. without NAPTR as defined in RFC 3403).  That's
around 370 lines of code in my reference implementation.

-- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org