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

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 5 Jul 2003 19:24:30 -0500

> 
> Because support for wildcards is a MUST when you implement the NAPTR 
> record, which ENUM inherits from the DDDS application. If you don't 
> implement it, you loose. You don't have a DDDS compliant 
> implementation.
> 

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.

[from another mail]
> You can have something like this (I think, straight from my head):
> 
> 1.2.3.4.e164.arpa. IN CNAME 4.e164.arpa.
> 2.2.3.4.e164.arpa. IN CNAME 4.e164.arpa.
> 3.2.3.4.e164.arpa. IN CNAME 4.e164.arpa.
> 
> 4.e164.arpa. IN NAPTR .... "!^+4(.*)$!sip:9876\[email-masked]!"

I had thought that the reason that the reason such examples were removed
from rfc2916bis is that we wanted to pass over this issue of partial E.164
numbers in silence. 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.

Wildcarding is, I agree, a separable issue. But I guess I am also a little
unclear, given the example above, how delegation from 4.e164.arpa to the
subdomains works - would there be additional records under 4.e164.arpa
besides that NAPTR that indicate delegation? Many of the partial number
cases (including the one Martin showed us) do entail some wildcarding,
anyway.

Jon Peterson
NeuStar, Inc.

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 6 Jul 2003 06:22:46 +0200

> behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis

Why should they ignore it? They still have to _implement_ it.

> numbers in silence.

No, the example was removed because it contained a wildcard in DNS.

> The restriction in the sipping-e164 document basically

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]!"

          paf