Subject: AW: AW: [Enum] partial numbers proposed text changes

From: "Stastny Richard" <[email-masked]>
Date: Tue, 25 Mar 2003 21:13:12 +0100

Hi MM,
we are talking two different things here, because of a terminology problem.
A non-E.164 number is a number not in the E.164 numbering plan, e.g 911.
 
What you mean is a "full E.164 number" as defined in E.164 containing 
CC N(S)N SN. What this is is defiend nationally. And some countries
like Austria and Germany allow (unlimited) direct-dial-in behind the SN to
extension numbers
 
So your formulation would either disallow to enter the extensions in ENUM
or disallow to enter the pilot number in ENUM. Both may be dialled on the PSTN
 
So your proposal excludes some valid E.164 numbers to be entered in ENUM,
which I strongly oppose for two reasons:
 
1. All E.164 numbers shall be possible in principle in ENUM
2. Which valid E.164 numbers are not to be entered in ENUM is an 
ITU-T and/or national matter.
 
best regards
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Michael Mealling [mailto:[email-masked]] 
	Gesendet: Di 25.03.2003 20:46 
	An: Stastny Richard 
	Cc: [email-masked] 
	Betreff: Re: AW: [Enum] partial numbers proposed text changes

	On Wed, 2003-03-19 at 16:18, Stastny Richard wrote:
	> I propose the last sentence of the text to be deleted, because this is not possible anyway:
	> 
	> "Because of this risk for
	> collissions, the flag E2U in the service field MUST NOT be used for
	> non-E.164 numbers."
	
	It is very possible...
	
	> Reason:
	>
	> According to the delegation policy within e164.arpa only domains mapping to valid E164 numbers may be created within the e164.arpa tree anyway. It is therefore not possible to create a domain with non-E164 within e164.arpa in the first place. Therefore there is no way to enter a NAPTR with E2U in such a non existing domain.
	>
	
	The fact that you insert '.' in between each number by the definition of
	how the DNS works, you have created an intermediate node at each and
	every point. 6.5.6.9.1.8.5.8.7.6.1.e164.arpa has 10 levels of
	intermediate DNS nodes. They're not valid according to ENUM but they are
	valid DNS labels and as such there is a non-zero chance that a client,
	not knowing anything about the US numbering plan, would query
	for a NAPTR record for some portion of that hierarchy.
	
	You may come to the conclusion that such a thing might be illegal but
	that's because you've been thinking about this for a while and you
	approach if from the standpoint of "that which is not explicitly allowed
	is illegal". Typical Internet developers use the "conservative in what
	you send, liberal in what you receive" method. That means many will read
	it just the opposite: "that which is not explicitly disallowed will be
	found 'in the wild' and thus is mandatory". If it is illegal then what's
	the harm of saying it explicitly?
	
	-MM

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

---

From: Michael Mealling <[email-masked]>
Date: 26 Mar 2003 11:29:25 -0500

> A non-E.164 number is a number not in the E.164 numbering plan, e.g 911.

yep... got that...

> like Austria and Germany allow (unlimited) direct-dial-in behind the SN to

Correct. And because of that there is no way for a client application to
know with 100% certainty that it has a fully qualified E164 number,
correct?

> ITU-T and/or national matter.

How did you come to the conclusion that I'm disallowing any E164 number?
What I'm saying is that a number that isn't valid, but is syntactically
correct, but which is also a subset of a valid number MUST not have any
NAPTRs associated with it that contains 'E2U' in its Service field.
Since I don't know if +99-209 is valid or not the only thing I can do is
check it for syntax. I'm not 100% up on E164 syntax but from what I
heard last week that is syntactically correct. If someone in France were
to read this document and it said nothing about putting records at the
interim 9.0.2.9.9.e164.arpa they may very well be tempted to do so.
Which would cause my client to get an NAPTR record back for something
that it shouldn't be able to do so.

Hmm.... let me state this differently: E2U NAPTR records MUST not be
inserted for numbers that are inconsistent with the numbering plan it
appears under. I.e. if a number is invalid according to the numbering
plan it must be invalid for ENUM as well. Is that better?

-MM