[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:
> I just posted a bug (#844) concerning ENUM NAPTR-records.
> I found the following NAPTR-records:
> 184.108.40.206.220.127.116.11.18.104.22.168.4.e164.arpa NAPTR 100 100 "u" "E2U+h323"
> "!^\\+4971163314(.*)$!h323:\\1 at foxi.vc.dfn.de!i" .
> 22.214.171.124.126.96.36.199.188.8.131.52.e164.arpa 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