Subject: FW: [Enum] Summary and Minutes of ENUM in Washington

From: "Anne Brown" <[email-masked]>
Date: Mon, 6 Dec 1999 09:51:52 -0600

Alfred,

Given the fact that DNS queries for E.164 numbers will have e164.int or
something similar as a top level domain name, thus leaving no ambiguity as
to whether the number is an E.164 number,  I am not sure what problem the
AESA field solves. 

Regards,
Anne 

-----Original Message-----
From:	Albert Manfredi [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]> 
Sent:	December 03, 1999 12:01 PM
To:	Brown, Anne [NORSE:6L47-I:EXCH]; 'ENUM'
Subject:	RE: [Enum] Summary and Minutes of ENUM in Washington

Anne,

I'm not sure your response addresses Christian's concern. Maybe it does, but
I took it differently.
To me, the question is "how does a host send a DNS request, with an E.164
telephone number in it, in such a way that the DNS knows that the number is
in fact E.164?" To understand the question, it was one reaction to my
suggestion of making the E.164 number a field that is _peer_ to the IP
address. Not part of an IP name, as has been proposed here.
Since I believe that the 20-byte AESA field already exists in the DNS
database format, I also believe that the answer to Christian's concern
should be quite elegant. When you request a resolution of an E.164 number,
the field used in the request is the AESA field. The number is encoded as an
encapsulated E.164 address, the AFI byte up front is set to 0x45, and there
is no ambiguity. And this is expandable in the future.
In other words, this is a different scheme from the one discussed in DC.
Telephone numbers get their own field, using the field allocated now to
AESAs.
Bert
[email-masked] <mailto:[email-masked]> 

-----Original Message-----
From:	[email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] <mailto:[mailto:[email-masked]]> On Behalf
Of
	Anne Brown
Sent:	Friday, December 03, 1999 10:31 AM
To:	'ENUM'
Subject:	FW: [Enum] Summary and Minutes of ENUM in Washington

Alfred,
In response to Christian's question "How do you know you have an E.164
number?",  a person today is expected to know the difference between a local
and an E.164 number in order to make a phone call.  In the future we, or an
application on our behalf, will be able to lookup a telephone number, given
some input information.  I would hope that an E.164 number is returned, if
the request was to a global service (i.e., not a request to a local service
or directory).  I would also hope that the user would never see the number,
but only verify the intended recipient before commencing with the session.
Regards,
Anne
-----Original Message-----
From:	Albert Manfredi [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]> 
Sent:	December 02, 1999 5:10 PM
To:	Scott Petrack; enum
Subject:	RE: [Enum] Summary and Minutes of ENUM in Washington
	> There followed some "animated discussion"  on the subject
	> of how one
	> can tell if a given number is part of the E164 domain or
	> if it belongs
	> to some other domain:
	>
	>       Dave Oran asked how the client could know if a
	> given number belongs
	> to e164.int or something else.
	>
	>       Scott Petrack said that this is within the scope of ENUM.
	>
	>       Scott Bradner said that we don't want to spend time
	> on what goes
	> on the "right hand side of the @ sign".
One point that wasn't mentioned in the minutes. This discussion took place
at the close of the session.
As I understand it, the DNS today has a peer field to the IP address which
is an ATM End System Address (AESA). Is this so?  If this is so, then why
not use that field for E.164, which is after all already an accepted format,
encapsulated by the 20-byte AESA frame?
Now you don't have to worry about the incredibly long series of numbers and
dots to the left of an @ symbol. You simply have a third field to search on.
So a name can be mapped to an IP address and an AESA (which incorporates
E.164).
Christian Huitema brought up the question, "How do you know you have an
E.164 number?" My first answer _was_ that it is preceded by a + symbol. But
in fact, a much better answer is that the 20-byte AESA field has an AFI
(Authority and Format Identifier) byte as its first byte, and that is used
to identify E.164. There are also two other possible formulations of the
20-byte AESA already standardized, which could be used here as well. And
potentially many more, including possible multicast or even portable
telephone numbers.  (Okay, this is outside the enum scope.)
What's wrong with this approach, given that DNS already is set up for the
AESA?
Bert
[email-masked] <mailto:[email-masked]> 

_______________________________________________
enum mailing list
[email-masked] <mailto:[email-masked]> 
http://www.ietf.org/mailman/listinfo/enum
<http://www.ietf.org/mailman/listinfo/enum> 

_______________________________________________
enum mailing list
[email-masked] <mailto:[email-masked]> 
http://www.ietf.org/mailman/listinfo/enum
<http://www.ietf.org/mailman/listinfo/enum>

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 6 Dec 1999 14:02:04 -0500

Well, you have a point, Anne. Why even bring this up [the idea of
using the AESA field in the DNS to carry E.164 numbers, instead of
the "name" field with  number before the @ symbol]?

Perhaps I have three answers to this question:

1. It formalizes the E.164 number (and any other numbering scheme
such as DCC or ICD, or potential future numbering schemes) in a
structure that already exists, ensuring that duplication of
telephone numbers under numerous _name_ field listings will not
occur in DNS.

2. This might be controversial, but such a scheme would combine the
functions of the DNS and the ANS into possibly the same set of
servers. Or viewed another way, it incorporates other addressing
schemes within the Internet, with (I believe?) minimal bother. It
allows one to dial a number, as easily as one now types in the IP
address or name. All you have to know is the number. After all, it
should be as globally unique as an IP address, right?

3. It just seems like a logical alternative to be considered. Query
based on one of those fields, response provides all other
identifiers for the target host. I guess I was surprised when it
hadn't been (as far as I could tell) examined as a possibility.

I would agree that none of these is compelling to the point that "no
other way would work." However, it just seems that some of the
kludge factor is eliminated?

Bert
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Anne Brown
Sent: Monday, December 06, 1999 10:52 AM
To: 'ENUM'
Subject: FW: [Enum] Summary and Minutes of ENUM in Washington

Alfred,
Given the fact that DNS queries for E.164 numbers will have e164.int
or something similar as a top level domain name, thus leaving no
ambiguity as to whether the number is an E.164 number,  I am not
sure what problem the AESA field solves.
Regards,
Anne
-----Original Message-----
From:   Albert Manfredi [mailto:[email-masked]]
Sent:   December 03, 1999 12:01 PM
To:     Brown, Anne [NORSE:6L47-I:EXCH]; 'ENUM'
Subject:        RE: [Enum] Summary and Minutes of ENUM in Washington
Anne,
I'm not sure your response addresses Christian's concern. Maybe it
does, but I took it differently.
To me, the question is "how does a host send a DNS request, with an
E.164 telephone number in it, in such a way that the DNS knows that
the number is in fact E.164?" To understand the question, it was one
reaction to my suggestion of making the E.164 number a field that is
_peer_ to the IP address. Not part of an IP name, as has been
proposed here.
Since I believe that the 20-byte AESA field already exists in the
DNS database format, I also believe that the answer to Christian's
concern should be quite elegant. When you request a resolution of an
E.164 number, the field used in the request is the AESA field. The
number is encoded as an encapsulated E.164 address, the AFI byte up
front is set to 0x45, and there is no ambiguity. And this is
expandable in the future.
In other words, this is a different scheme from the one discussed in
DC. Telephone numbers get their own field, using the field allocated
now to AESAs.
Bert
[email-masked]

[email-masked]