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 <[e-mail]>]

Hi Andrew,

Andrew Newton wrote:
> 
> On Oct 16, 2009, at 1:09 PM, Ted Hardie wrote:
> 
>>>
>>> There was not many opaque URI defined in standard track since RFC
>>> 3986, but the
>>> IRIS URI (RFC 3981 section 7.1) looks like an opaque URI that reuse
>>> components
>>> from RFC 2396 and RFC 2732.
>>>
>>> Anyway, I can copy and rename the definitions that I need from RFC
>>> 3986 if it is
>>> what is needed.
>>>
>>
>> IRIS is an interesting model here, as it is one of the few others to
>> really use S-NAPTR.  I've cc'ed Andy on this message to ping him to
>> take a look at your draft.  IRIS's complexity is pretty substantial on
>> a number of fronts, and the URI resolution is certainly
>> one of the areas where the complexity has daunted some of those
>> interested in the protocol.  It's also noteworthy that IRIS created a
>> very rigid URI, with a very flexibile resolution mechanism.  I'm not
>> sure, honestly, that approach was a success.
> 
> Marc, Ted,
> 
> I'm unsure of what insight I can offer here.  The TURN URI scheme does
> seem to mix "layers" of the resolution process, or at least as I've
> thought about it in the past.   But that may just be me and my limited
> understanding of what is trying to be accomplished by the TURN URI.
> 
> 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
> 
> This discussion would also benefit from anybody with knowledge of or
> implementation experience with generic URI parsers, as that would be a
> point of interoperability.

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 Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org