Discussion List for Freenum/ITAD Subscriber Number (ISN) Project

[John Todd <>]

At 11:15 PM -0400 2006/9/27, 

 wrote:
> As far as I can tell from reading the current RFC that governs NAPTR
> records, RFC 3402 section 3.2, the substitution specified in the NAPTR
> record must be applied to "the String" in a similar manner as is done
> by the "sed" program, which is that the substring that is matched by
> the regexp is to be replaced by the string generated by the
> replacement field.  What this turns "the String" into is (in our case)
> the result of the NAPTR, which is to be a URI.
>
> The de-facto standard for ISN NAPTR records is given in the ISN Cookbook:
>
> *.xxx.freenum.org IN NAPTR 100 10 "u" "E2U+sip" \
>         
> "!^\\+*([^\\*]*)!sip:\\!"
>  .
>
> The regexp is:
>
>         ^\\+*([^\\*]*)
>
> This matches any string with an initial sequence of "+", then any
> number of non-"*" characters.  The non-"*" characters are extracted as
> substring 1.
>
> Now "the String" for ISN lookup doesn't seem to be specified anywhere,
> but from the structure of this regexp, we can see that it's expected
> to contain a "*", following the organization-specific extension
> number, but the most reasonable hypothesis is that "the String" is the
> ISN number itself, possibly with a leading "+".
>
> But since the regexp doesn't match the whole ISN number, the
> substitution operation will progress like this:
>
> Input:
>         456*123
>         ^^^-------- part matched by regexp
>
>                     substring 1 = "456"
>
>                     replacement string = 
> "sip:"
>
> Output:
>         
> sip:*123
>
> Which isn't a URI, or at least, not the one we want.
>
> That is, the regexp needs to be changed to match the *whole* ISN
> number, so that the replacement string replaces it entirely.  An
> appropriate NAPTR would be:
>
> *.xxx.freenum.org IN NAPTR 100 10 "u" "E2U+sip" \
>         
> "!^\\+*([^\\*]*).*$!sip:\\!"
>  .
>
> There aren't a lot of authoritative examples of NAPTR records, that I
> can use to check that my interpretation is correct, but I can find
> these in the RFCs:
>
> rfc2168.txt:   IN NAPTR 100   10   ""  "" 
> "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
> rfc2915.txt:   IN NAPTR 100   10   ""  "" 
> "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
> rfc2915.txt: IN NAPTR 100 10 "u" "sip+E2U" 
> "!^.*$!sip:!"     .
> rfc2915.txt: IN NAPTR 102 10 "u" "mailto+E2U" 
> "!^.*$!mailto:!"  .
> rfc2916.txt:   IN NAPTR 100 10 "u" "sip+E2U" 
> "!^.*$!sip:!"     .
> rfc2916.txt:   IN NAPTR 102 10 "u" "mailto+E2U" 
> "!^.*$!mailto:!"  .
> rfc2916.txt:  IN NAPTR  10 10 "u" "sip+E2U"     
> "!^.*$!sip:!"
>     .
> rfc2916.txt:  IN NAPTR 102 10 "u" "mailto+E2U"  
> "!^.*$!mailto:!"
>  .
> rfc2916.txt:  IN NAPTR 102 10 "u" "tel+E2U"     "!^.*$!tel:+4689761234!"     .
> rfc2916.txt:   * IN NAPTR 100 10 "u" "ldap+E2U" 
> "!^+46(.*)$!ldap://ldap.se/cn=01!"; .
> rfc2916.txt:    IN NAPTR 10 10 "u" "sip+E2U" 
> "!^.*$!sip:!"        .
> rfc2916.txt:    IN NAPTR 10 10 "u" "mailto+E2U" 
> "!^.*$!mailto:!"     .
> rfc2916.txt:    IN NAPTR 10 10 "u" "http+E2U" 
> "!^.*$!http://svensson.ispa.se!"; .
> rfc2916.txt:    IN NAPTR 10 10 "u" "tel+E2U" 
> "!^.*$!tel:+46-8-9761234!"       .
> rfc2916.txt:    IN NAPTR 10 10 "u" "sip+E2U" 
> "!^.*$!sip:"        .
> rfc2916.txt:    IN NAPTR 10 10 "u" "mailto+E2U" 
> "!^.*$!mailto:"     .
> rfc2916.txt:    IN NAPTR 10 10 "u" "http+E2U" 
> "!^.*$!http://svensson.ispa.se"; .
> rfc2916.txt:    IN NAPTR 10 10 "u" "tel+E2U" 
> "!^.*$!tel:+46-8-9761234"       .
> rfc3403.txt:  IN NAPTR 100   10   ""    "" 
> "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i"    .
> rfc3403.txt: IN NAPTR 100 10 "u" "sip+E2U" 
> "!^.*$!sip:!i"     .
> rfc3403.txt: IN NAPTR 102 10 "u" "smtp+E2U" 
> "!^.*$!mailto:!i"  .
> rfc3404.txt:IN NAPTR 100   10   ""    ""  "!^cid:.+@([^\.]+\.)(.*)$!\2!i"    .
> rfc3761.txt:      NAPTR 10 100 "u" "E2U+sip" 
> "!^.*$!sip:!"
>  .
> rfc3761.txt:      NAPTR 10 101 "u" "E2U+h323" 
> "!^.*$!h323:!"
>  .
> rfc3761.txt:      NAPTR 10 102 "u" "E2U+msg" 
> "!^.*$!mailto:!" .
> rfc3764.txt:   IN NAPTR 10 100 "u" "E2U+sip" 
> "!^.*$!sip:!"     .
> rfc3824.txt:    IN NAPTR 100 10 "u" "E2U+sip" 
> "!^.*$!sip:!"     .
> rfc3824.txt:    IN NAPTR 100 20 "u" "E2U+mailto" 
> "!^.*$!mailto:!"  .
> rfc3953.txt:   IN NAPTR 100 10 "u" "E2U+pres" 
> "!^.*$!pres:!"
>
> In *all* of these examples, the regexp starts with "^" and ends with
> "$", apparently to indicate that it should match the entire input
> string (so that the entire input string can be replaced).
>
> So it looks like the ISN system is not conformant with the definition
> of NAPTR records right now, and we need to change the standard ISN
> NAPTR record to:
>
> *.xxx.freenum.org IN NAPTR 100 10 "u" "E2U+sip" \
>         
> "!^\\+*([^\\*]*).*$!sip:\\!"
>  .
>
> Dale

Dale -
  I'm one of the leading non-experts on regexps, so I can't say if 
this is a valid or invalid point.   Let me put out some additional 
comments:

  1) A modified NAPTR configured with the updated regexp as you 
describe has been installed for ITAD 256 (mine.)  Asterisk correctly 
parses the regexp to come up with the correct result (try "1234*256" 
and it should result in )

  2) Asterisk and SER seem to have been working correctly with the 
existing "suggested default" NAPTR record that is in place for most 
other participants currently.  Is this due to inherent regexp 
failures within the two most popular parsing engines (Asterisk and 
SER/OpenSER) or is the current regexp actually correct?

  3) It's not difficult for us to change the majority of the NAPTRs 
that currently exist on the ISN testbed, since most organizations 
have opted to have their NAPTRs held in the "root" zone instead of 
taking the delegations themselves.  However, I'd like to ensure that 
this is fully validated before we would take such a suggestion or 
action.

JT