Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 8 Jul 2003 09:54:47 -0400

Without speaking to the DNS wildcarding issue as a whole, I suppose that
given the public outcry we should pass over this whole greedy regexp issue
in silence in sipping-e164. Though ultimately I believe that the use of
non-greedy regexps in ENUM encourages NAPTR records for partial numbers
(which in turn encourage wildcarding, etc), I certainly don't feel strongly
enough about this that I think we need to mandate against it, and I guess I
could just drop the current RECOMMENDation.

Some other notes below.

Jon Peterson
NeuStar, Inc.

> >
> > I'm not suggesting that clients refuse to process records with more
complex
> > regexp antecedents if they happen to receive them - this is in a section
of
> > advice for authors of NAPTR records, not a specification of resolver
> > behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis
> > compliance in any way.
> 
> Why should they ignore it? They still have to _implement_ it.

The people or systems that create the NAPTR records which are provisioned in
the DNS do not have to 'implement' resolvers.

[snip]
> 
> > The restriction in the sipping-e164 document basically
> > reinforces this (at a RECOMMENDED level, not as a mandatory statement),
but
> > given that this seems to be a controversial matter, perhaps it would be
best
> > if we passed over this in silence in the SIPPING document as well.
> >
[snip]
> 
> This has _nothing_ to do with partial numbers.
> 
> Let's then change the example to:
> 
> 1.2.3.4.e164.arpa. IN CNAME foo.bar.example.com.
> 2.2.3.4.e164.arpa. IN CNAME foo.bar.example.com.
> 3.2.3.4.e164.arpa. IN CNAME foo.bar.example.com.
> 
> foo.bar.example.com. IN NAPTR .... 
> "!^+4(.*)$!sip:9876\[email-masked]!"
> 

Well, all right, given this clever example, I agree that authors of records
don't necessarily have to use partial E.164 numbers in order to use a
non-greedy regexp antecedent in NAPTRs. But, authors of records don't really
have any incentive to make records structured like this, in which you have
to enumerate every number in the numbering plan in a CNAME record. Rather,
they want to have a single NAPTR record for a partial number (as in the
other examples aired on the list have suggested).

>           paf

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 8 Jul 2003 16:29:44 +0200

> could just drop the current RECOMMENDation.

Personally, I would appreciate you dropping it. People implementing 
things should not "just implement what they need" (which often is a 
partial solution). I (and many  with me) remember when MIME was started 
to be adopted where text/plain messages could have a charset parameter. 
Many many implementations didn't implement the 
Content-Transfer-Encoding mechanism, and only took for granted ISO 
8859-1 was in use. When they later launched services and had customers 
in for example Japan, they didn't understand what was wrong...

You have probably seen similar things with SIP...

Better write implementation guidelines which are written so people can 
not cheat. If they do anyway, they must definitely know what they are 
doing (and why they are cheating).

And, I agree with you that the ones doing the provisioning are not the 
same writing the code. BUT, writing the code and get it to work is a 
one-time-thing, although difficult.

With experience from Cisco implementing the whole-nine-yards I can tell 
you the problem is not the regexp engine. The problem is to get the 
configuration tool working correctly so the _selection_ of NAPTR 
records is correct, and possible to understand for the one which 
configure whatever the programmer is creating.

     paf

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 14 Jul 2003 13:36:03 +0200

On 2003/07/08 16:07, Patrik Fältström <[email-masked]> wrote:
> you the problem is not the regexp engine. 

FYI, I implemeted the full regex substitution algorithm for the 
Asterisk PBX last week. Calls to Marian utilizing his wildcard NAPTRs
worked fine. Based on the Posix regex functions included in
the Linux libc, that took about 3 hours and 50 lines of C code.
(and some glances at how ser is doing that stuff.)

Bringing the code for full precedence/multiple NAPTRs/multiple
servicespecs in one NAPTR/tel:-recursion (if needed) - handling up to
RFC compliance gives me more headaches.

From my point of view, there are the real pitfalls for ENUM resolver
implementations.

/ol