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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf