Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 10 Aug 2000 14:53:10 -0400

> -----Original Message-----
> From: Michael Mealling [mailto:[email-masked]]
> 
> On Thu, Aug 10, 2000 at 01:42:57PM -0400, Manfredi, Albert E wrote:
> > Or am I missing something here?
> 
> I think the issue is more along the lines of allowing future 
> extenstibility.
> I.e. if we don't put the "+" in there now then it makes it much
> harder for us to work around it in the future. Much like the issue
> surrounding the MIME version header. Its supposed to never change from
> version 1.0 but it was thought best to put it in there "just in case"
> we realized something latter.
> 
> I.e. if you put the "+" in there now it doesn't cause any real pain.
> But in the future if you want to tell the difference and it 
> isn't there
> then it makes life really suck....

[Chuckle.]

The counter argument is very simple, however, and has been made a couple of
times: use of + does not nearly provide enough flexibility for the future
anyway. All that does is make use of e.164 clear. It offers little for
growth. It provides few options for specifying _other_ numbering plans.

It seems that the consensus is that the actual request is sent to DNS as
1.2.3.4.5.6...7.8.e164.arpa, without a +. If that's the case, then the +
issue only applies to how the user types a request in his computer. Let's
leave that aside, since it really is not enum material.

As far as the DNS goes, the more "obvious" way to handle future non-e164 DNS
requests for telephone numbers is to request them to other than e164.arpa.
For example, you might type a telephone number in the Italian numbering
plan, and that request might go out as
1.2.3.4.5.6...7.8.9.numeri.telecomitalia.it, which might be a server that in
turn converts the numbers to e.164 for the request, perhaps. (Or perhaps it
only converts to e.164 the requests for international numbers, and returns
directly the URIs for Italian numbers.)

Point being, the DNS request for e.164 will be easily differentiated from
DNS requests for anything different. A + is either not applicable to enum
(because it doesn't appear in the actual DNS request), or it is not
necessary (if you assume it _should_ appear in the actual DNS query), IMO.

Bert
[email-masked]

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

---

From: Michael Mealling <[email-masked]>
Date: Thu, 10 Aug 2000 15:03:06 -0400

> growth. It provides few options for specifying _other_ numbering plans.

By itself, yes. 

> leave that aside, since it really is not enum material.

Sure. But the plus is stripped before that. Its not the DNS stuff
that is using the "+" its the NAPTR rewrite rule. The regular expression
is applied to the original, non-DNS encoded number. The issue is whether
you want to remove the plus from _that_ string.

> necessary (if you assume it _should_ appear in the actual DNS query), IMO.

The issue isn't really evident during the first iteration through the
DDDS algorithm. Its more evident and useful if the NAPTR record does
not contain a "u" flag and thus indicates that the output of the 
regular expression is NOT an ENUM endpoint but a new  domain-name
for which more NAPTR records will be requested. These new domain-names
may not be in the e164.arpa zone so you may have cross over with other
numbering schemes. This is specifically warned about in the DDDS DNS
doc and its suggested solution is to just not delegate two rewrite paths
into the same zone. But having the plus in the number that is used
as the input to the rewrite rule is a good way to make sure this
doesn't happen.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Aug 2000 21:27:02 +0200

>leave that aside, since it really is not enum material.

You have to differ between the DNS request and what is the input to 
the NAPTR algorithm. In DNS we have no '+', in the NAPTR algorithm we 
have.

   paf