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 componentsfrom RFC 2396 and RFC 2732.Anyway, I can copy and rename the definitions that I need from RFC 3986 if it iswhat 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/pysnaptrThis 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