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

[Andrew Newton <[e-mail]>]

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.

-andy