On 2005/11/03 15:11, Juha Heinanen <[EMAIL PROTECTED]> wrote: > i read the internet draft and don't have anything against its ideas. > i didn't read the code in order to figure out, how it acquires the BLR > information, which was pretty much left an open issue in the draft. a > new rr hardly comes into question.
No need to read the code, it's in the documentation: +1.3.5. bl_algorithm (string) + + This parameter determines which algorithm carrier_enum_query() + will use to select the position in the DNS tree where the + carrier tree branches off the user ENUM tree. + + If set to "cc", carrier_enum_query() will always inserts the + carrier label at the country-code level. Examples: + carrier.1.e164.arpa, carrier.3.4.e164.arpa, + carrier.2.5.3.e164.arpa + + If set to "txt", carrier_enum_query() will look for a TXT + record at + [branchlabel].[reverse-country-code].[carrier_suffix] to + indicate after how many digits the carrier label should in + inserted. + + Example 1-5. Zone file example +carrier.1.e164.arpa. IN TXT "4" +9.9.9.8.7.6.5.carrier.4.3.2.1.e164.arpa. IN NAPTR "naptr content for + +1 234 5678 999" + + Default value is "cc" I intentionally made that a config option to accomodate an evolving standard. My patch does not change the semantics of the existing enum_query() functions. > so i would suggest that this code is incorporated into current enum > module if the draft becomes ietf working group document AND the BLR > issue has been decided. after that the code is not likely to need heavy > future modification. I can live with that. /ol -- < Otmar Lendl ([EMAIL PROTECTED]) | nic.at Systems Engineer > _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
