On 2005/11/01 11:11, Juha Heinanen <[EMAIL PROTECTED]> wrote: > Otmar Lendl writes: > > > I've added support for the carrier ENUM setup as described in > > draft-haberler-carrier-enum-01.txt. This code is indended to > > facilitate a trial. This certainly is not the final release as > > the spec itself is in flux. > > the spec is not even a working group draft.
Yes. It's the old chicken/egg problem: What's first? The code or the standard. Given the IETF motto, we decided not to wait until the RFC before we start implementing this idea. > > Anyway: please have a look and give me some indication whether > > the patch could be incorporated into the default openser release. > > since i have been maintaining enum module, i would like to know if this > patch some has performance impact on enum function as used currently? Basically the change moves the main code from enum_query_2 to a new function enum_query_3 in which the additional code is only execute if carrier enum was desired. So, maybe one function call overhead plus one "if" statement. The minor rearrangement I made in the string-handling should be performance-neutral. > also, would you be willing to maintain enum module if this patch is > incorporated? Short term, probably yes. Longer term is a question which my boss has to answer. > in my opinion, these kind of experimental features should be done using > experimental modules until the feature stablilizes and is found > generally useful. I thought of that as well, but then decided against duplicating a lot of code into a new module. After all, my changes only affect the "turn number into domainname"-part of ENUM and not the much trickier NAPTR parsing and selection. Any changes to the original enum module are very likely to apply to a spinoff module as well, so weighed the maintenance hassle of two almost identical modules against the introduction of an experimental feature in a mature module. The make future reintegration with the main trunk easy such an experimental module would look exactly like my patched enum module. Anyway, there is an IETF meeting next week and this should give me some direction on the protocol evolution. If it's the consensus here that such trials should not happen in the current enum module, I'll fork the module. /ol -- < Otmar Lendl ([EMAIL PROTECTED]) | nic.at Systems Engineer > _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
