[Asterisk-Dev] ENUM NAPTR parsing problem

Conroy, Lawrence (SMTP) lwc at roke.co.uk
Wed Jan 14 15:34:39 MST 2004

Hi Maik, folks,
(i) I've just given a heads up on the IETF ENUM list for this
     particular piece of Mealling from RFC3402 section 3.2.

(ii) I tend to agree with the initial response to the bug -
      I'm unaware of *ANY* ENUM Client that handles this,
      so fixing * is the least of their problems if a registrant
      insists on exercising their right to put in this valid REGEXP.

(iii) Please, could someone paste into the bug the "normative" 
       not the URN example - it should be this quote from 3.2:
"  The "i" flag indicates that the ERE matching SHALL be performed in a
    case-insensitive fashion.  Furthermore, any backref replacements MAY
    be normalized to lower case when the "i" flag is given.  This flag
    has meaning only when both the Application and Database define a
    character set where case insensitivity is valid".

I would STRONGLY recommend that folks seeing one of these should
find the registrant and slap them around the face with a wet kipper.
Trying to change every ENUM Client in the World is going to be more
of a challenge, and much less gratifying.

The proposed fix does not actually process the REGEXP insensitively
as  specified in RFC3402, but doesn't SEEM to break other valid NAPTRs.

Be aware, however, that the existing enum.c has other limitations
(like only looking for ! as a delim) so it won't always work with
every standards-conforming NAPTR. Neither does any Client I've used.

Thus, the patch does what it's intended to do, but a wet kipper is
a better solution, IMHO - foxi watch out.

all the best,

On 14 Jan 2004, at 6:29 pm, Maik Schmitt wrote:

> Hi,
> I just posted a bug (#844) concerning ENUM NAPTR-records.
> I found the following NAPTR-records:
> NAPTR 100 100 "u" "E2U+h323"
> "!^\\+4971163314(.*)$!h323:\\1 at foxi.vc.dfn.de!i" .
> NAPTR 100 100 "u" "E2U+h323:voice"
> "!^\\+492241141(.*)$!h323:1\\1 at pbx-bi.corponet.info!i" .
> Asterisk cannot parse those records because of the 'i' at the
> end but the record is valid (see RFC 3403 6.1 for an example). The 'i'
> means case insensitive matching (very useful....).
> I wrote a simple patch for this. I know it is a quick and dirty-patch
> but it works and doesn't break anything. Maybe someone could have a
> look at it...
> -- 
> Maik Schmitt        http://graphics.cs.uni-sb.de/VoIP

Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.

More information about the asterisk-dev mailing list