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

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

> -----Original Message-----
> From: Hong Liu [mailto:[email-masked]]
>
> Andy,
> 
> Thanks for the clarification. I agree with you that from a 
> user perspective, "+" means
> more than just for readability.
> 
> The problem we are discussing here is whether "+" is needed 
> for ENUM process given the
> fact that the input is a canonical E.164 number already. I 
> would like to hear from you
> and others. Thanks!

IMO, the + is nice, but isn't enough if we really want to think of this + as
a way to distinguish e.164 from some other numbering schemes we might want
to implement in DNS the future.

If the DNS query is made to domain e164.arpa, perhaps use of the + is
redundant and not particularly helful for the future anyway?

Bert
[email-masked]

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Aug 2000 16:37:44 +0200

>redundant and not particularly helful for the future anyway?

If we start using some more interesting parts of the NAPTR 
algorithms/possibilities, it is possible to have an input to the 
algorithm (output of first well-known-rule) that is either a full 
E.164 number or some other kind of telephone number.

Let's say that we have for phone numbers in Sweden the TLD e164.se.

A phone number in Sweden can look like "08-978777", which without the 
'-' is 08978777.

Let's store that in DNS:

7.7.7.8.7.9.8.0.e164.se.

What do we now do?

Well, we can use the string we got 08978777 as input to a NAPTR 
rewrite mechanism where the flag field is empty, and because of that 
forces the rewrite to loop.

We can then store

7.7.7.8.7.9.8.0.e164.se. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" .

In parallell we have the full E.164 number +46-8-978777 (the same 
number) which have the DNS record 7.7.7.8.7.9.8.6.4.e164.arpa.

That NAPTR can look like

7.7.7.8.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "" "" "![0-9].*!foo.se!" .

Now, at foo.se, we want to distinguish between the "referals" which 
have been made from non-E.164 numbers and the ones which uses the 
full number (think of the two as two different dialling plans). How 
do we do that?

Well, the input to the algorithms are 08978777 and +468978777, and 
because of this different. We can because of that have two different 
NAPTR RRs at foo.se as follows:

foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "!+.*!mailto:[email-masked]!" .
foo.se. IN NAPTR 10 10 "u" "mailto+E2U" "![0-9].*!mailto:[email-masked]!" .

Note that the regular expressions are different, and because of that 
only one of the two will match, and according to the NAPTR algorithm 
one should use the regexp which matches given that the repacement 
field is empty.

Also, note (of course) that the URIs which should be used are different.

So, I _really_ want the '+' there so it is simpler to know that we 
are talking about a real E.164 number and not something else 
(regardless of what it is) when dealling with regular expressions.

As usual, Michael will jump in if I have made an error :-)

     paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 10 Aug 2000 10:48:37 -0400

> As usual, Michael will jump in if I have made an error :-)

Looked fine to me....

-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: Hong Liu <[email-masked]>
Date: Thu, 10 Aug 2000 11:44:41 -0400

Patrik,

Thanks for giving out the example in the email. Now I understand the need to
distinguish a true E.164 number from other national or corporate numbering
plan, when ALL these services are hosted by the SAME service provider.

Your example builds on three assumptions:
(1) The ENUM mechanism, not ENUM itself, will be used in situations other
than E.164 to URI mapping.
(2) A service provider may co-host NAPTR RRs for the different ENUM-like
services of the same user. (Here I use the word "user" in a very loose way.)
(3) The application has the knowledge of which numbering plan it is using;
otherwise it will not know which name space to query in the first place.
Hence, the application knows which _service_ it is requesting.

I would not argue whether (1) is really within the charter of ENUM, but let's
assume that this is going to happen independent of whether ENUM include other
similar services or not. I just want to emphasize that there will be many
ENUM-like _services_ coexisting, and they are in fact _different_ services.
(Personally, I think it is a good thing to see the same mechanism be used in
various situations.)

I acknowledge the need to distinguish the services by the way a phone number
is presented, but I would argue that by just putting a '+' for an E.164
number is not sufficient to address the need. How are you going to tell one
non-E164 number from another non-E164 number? In this case, '+' will not be
able to do much.

To solve this problem, I would suggest that we use the 'rs' field instead.
This proposal builds on the emails from both James Yu and Al Manfredi.
Specifically, 'E2U' is currently defined for ENUM. For other numbering plans,
others can also define 'E212toU' for IMSI, 'E214toU' for global title,
'UPT2U' for UPT number, 'SE2U' for national numbers in Sweden, etc... Of
course, this is an idea, the exact details need to be worked out. The point
here is each additional service can be distinguished by defining a new
service code point in 'rs'.

By reading the DDDS algorithm in draft-ietf-urn-ddds-00.txt, the application
MUST check the services field after the substitution to decide whether the
resulting string.

This proposal has the following advantages: First, this provides an
extensible way of using ENUM in many other similar applications without
clashing the name space. Second, it helps to tell people why it is important
to define E2U in ENUM. Third, by removing '+' specifically for E.164, it
makes the ENUM algorithm uniform in treating any numbering plans. However, it
has one disadvantage: the resolution system may need to return all the NAPTR
RRs to the application. But since it normally at the last step of the
resolution process, I would not expect too many records to be returned for a
particular 'user'.

--Hong

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Aug 2000 17:58:39 +0200

>Hence, the application knows which _service_ it is requesting.

Correct.

>(Personally, I think it is a good thing to see the same mechanism be used in

I agree completely.

>non-E164 number from another non-E164 number? In this case, '+' will not be

They can for each numbering plan tell exactly what input string they 
are using for their version of the NAPTR algorithm. My personal one 
might be "Take the number, add the string 'paf' in front of the 
digits" in step 2, so the number "42" (I only have 2 digits in the 
phone numbers in my numbering plan) will be turned into "paf42" 
before starting matching in regexp in NAPTRs.

>service code point in 'rs'.

Ok.

>MUST check the services field after the substitution to decide whether the

That is absolutely correct.

>RRs to the application.

It always pass back all NAPTRs.

And, I still don't understand why we should not follow the 
recommendation from ITU.

Is it because you don't want to include the '+' in the regexp?

Is it because you feel "!.*!mailto:[email-masked]!" is weird when it 
tries to match "+468978777", and that matching "468978777" is better?

I.e. you say "Third, by removing '+' specifically for E.164, it makes 
the ENUM algorithm uniform in treating any numbering plans.".

I don't get this. ITU have asked the '+ to be there first of all, and 
secondly I ask how it can become "uniform"?

>But since it normally at the last step of the

    paf

---

From: Hong Liu <[email-masked]>
Date: Thu, 10 Aug 2000 15:38:26 -0400

Patrik, Mike and others,

It seems that the discussion on whether '+' is needed in ENUM algorithm leads to
the issue of extensibility of ENUM algorithm for other applications. The question
here is how to differentiate one resolution service from another, when the NAPTR
RRs for different services are hosted by the same server. For the sake of
simplicity, lets assume that all resolution services are concerned about mapping a
number to a set of URIs using NAPTR. They differ with the numbering plans each
deals with.

I have seen two proposals so far:

(1) The one proposed by Patrik. The essence of this proposal is to distinguish
each service by prepending a service-specific string before the number. In this
case, the ENUM service, which deals with fully qualified E.164 numbers, will use
'+' as the distinguishing flag. In fact, it could be anything as long as it is
unique for E.164 identification. Along this line, you may want to prepend a string
'imsi' for E.212 and 'gtt' for E.214, ... etc.

The key points for this proposal are:
(a) For each service, the Application Unique String (using DDDS terminology)
structure is different by the service-specific prefix.
(b) The substitution regexp can be fine tuned to each specific service using the
service-specific prefix.

(2) The second proposal by me is to treat all numbers, be it E.164 or others, as a
sequence of digits. The service will be differentiate from the 'rs' field of the
NAPTR record. In this case, we will have E2U for E.164, IMSI2U for E.212, GTT2U
for E.214,... etc. So the key points here are:

(a) The Application Unique String will have the same structure, just a sequence of
digits without any service-specific prefix. (This is what I meant by uniform in a
previous email.)
(b) Services are differentiated by the 'rs' field in the NAPTR RRs. In many cases,
the substitution regexp will be the same for all numbering plans, i.e. always
matched.

Both approaches accomplish the same goal, though I personally think the second
proposal is a cleaner way to enable extensibility for ENUM mechanisms. But I would
like to hear from the list how other people think. It is no longer the '+' issue,
it is the service extensibility and differentiation issue.

Note that both proposals requires that the client have a priori knowledge about
which service to request from a given the number, i.e., which name space to query.
The only difference is that in (1) the client needs to translate this knowledge to
a service specific prefix, while in (2) the client needs to translate this
knowledge to a service code point in 'rs'. The standardization of both the prefix
and the code point are equally tricky.

Provisioning of NATPR RRs for (2) MAY be simpler for regexp. It also allows
aggregation of services, say "mailto+E2U+IMSI2U+SE2U" when you want different
numbering plans all converge on sending a email to you. Anyway, I will stop here.

--Hong

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 11 Aug 2000 05:32:03 +0200

At 15.38 -0400 00-08-10, Hong Liu wrote:
>for E.214,... etc.

Two things:

(1) I am not saying you should not do this (aswell). What myself and 
Michael says is that it is unnessecary to remove the ability to 
distinguish in the regexp between numbering plans

(2) This I-D is for _proposed_ standard, next step is draft standard.

The distinction between them is as follows (see RFC 2026):

Proposed Standard:

    A Proposed Standard specification is generally stable, has resolved
    known design choices, is believed to be well-understood, has received
    significant community review, and appears to enjoy enough community
    interest to be considered valuable.  However, further experience
    might result in a change or even retraction of the specification
    before it advances.

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable, and will
    usually represent a strong argument in favor of a Proposed Standard
    designation.

    The IESG may require implementation and/or operational experience
    prior to granting Proposed Standard status to a specification that
    materially affects the core Internet protocols or that specifies
    behavior that may have significant operational impact on the
    Internet.

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.  However, the IESG may
    waive this requirement in order to allow a specification to advance
    to the Proposed Standard state when it is considered to be useful and
    necessary (and timely) even with known technical omissions.

    Implementors should treat Proposed Standards as immature
    specifications.  It is desirable to implement them in order to gain
    experience and to validate, test, and clarify the specification.
    However, since the content of Proposed Standards may be changed if
    problems are found or better solutions are identified, deploying
    implementations of such standards into a disruption-sensitive
    environment is not recommended.

Draft Standard:

    A specification from which at least two independent and interoperable
    implementations from different code bases have been developed, and
    for which sufficient successful operational experience has been
    obtained, may be elevated to the "Draft Standard" level.  For the
    purposes of this section, "interoperable" means to be functionally
    equivalent or interchangeable components of the system or process in
    which they are used.  If patented or otherwise controlled technology
    is required for implementation, the separate implementations must
    also have resulted from separate exercise of the licensing process.
    Elevation to Draft Standard is a major advance in status, indicating
    a strong belief that the specification is mature and will be useful.

    The requirement for at least two independent and interoperable
    implementations applies to all of the options and features of the
    specification.  In cases in which one or more options or features
    have not been demonstrated in at least two interoperable
    implementations, the specification may advance to the Draft Standard
    level only if those options or features are removed.

    The Working Group chair is responsible for documenting the specific
    implementations which qualify the specification for Draft or Internet
    Standard status along with documentation about testing of the
    interoperation of these implementations.  The documentation must
    include information about the support of each of the individual
    options and features.  This documentation should be submitted to the
    Area Director with the protocol action request. (see Section 6)

    A Draft Standard must be well-understood and known to be quite
    stable, both in its semantics and as a basis for developing an
    implementation.  A Draft Standard may still require additional or
    more widespread field experience, since it is possible for
    implementations based on Draft Standard specifications to demonstrate
    unforeseen behavior when subjected to large-scale use in production
    environments.

    A Draft Standard is normally considered to be a final specification,
    and changes are likely to be made only to solve specific problems
    encountered.  In most circumstances, it is reasonable for vendors to
    deploy implementations of Draft Standards into a disruption sensitive
    environment.

So, if I am wrong, we can "fix" this when we have more experience, 
when someone have written something about (I see these documents 
missing):

   - Use of LDAP as second step in E.164 resolution on the internet
     after the ENUM resolution (among others, VPIM people want this)
   - Use of ENUM-like services when having a closed numbering plan
   - Use of ENUM-like services with "sub-addressing" (or whatever it
     is called)
   - Use of ENUM in various countries (like USA and Sweden) where
     different schemes of number portability is in use already
   - The DDDS documents ready

I would not be surprised if we need to change things before going to 
"draft" standard, and maybe we even have to restart at "proposed".

I think this whole debate is premature, and that we today need the 
I-D as RFC so people can implement this stuff, so we get the 
experience we need to produce the next round of documents in the IETF 
(not necessary in the ENUM wg). As it is today, this spec is only an 
I-D which is a living target, can not be referenced, and because of 
that it is hard for for example the VPIM people to really start 
working on what they have knowledge about.

     Patrik

---

From: Hong Liu <[email-masked]>
Date: Fri, 11 Aug 2000 10:33:52 -0400

Patrik,

I would like to clarify a few points here:
(1) I am as interested as anyone else on the list to move the protocol spec
into the RFC status, so that everybody can implement. We are implementing it
now.
(2) In the spirit of moving forward, the changes I proposed can be
accommodated in the next revision of this document.
(3) Regarding the current document, the only change I suggested, including a
few others, is just to remove the '+' from the input string. This is _not_ a
very significant change. I don't see it in anyway will delay the document
from becoming an RFC because of that.
(4) Even if you go with the prefix+digits scheme, you still need to define
new service code for usage of ENUM in a non-E164 case, since E2U as currently
defined, only works for E.164 to URI mapping. In that sense, the two
proposals may complement each other as a last resort.

The bottom line: if the document is just for E.164 number mapping, the '+'
part is redundant. Since you suggested that we delay consideration of using
ENUM in other scenarios, then any hook, such as '+', should be removed to
leave this issue open for future considerations. As many people pointed out
on the list, '+' is just a kludge for a bigger problem of service
differentiation.

--Hong

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 11 Aug 2000 19:23:15 +0200

>from becoming an RFC because of that.

Can everyone that do care please let me know ASAP whether:

(a) You think the '+' makes sense
(b) You think the '+' should go away

Just be clear in your email (no arguments or explanation on why you 
think one way or another), and I can help the wg chair and the AD to 
find consensus.

    paf

---

From: Michael Mealling <[email-masked]>
Date: Fri, 11 Aug 2000 13:26:19 -0400

> (b) You think the '+' should go away

I pick "a". 

If its there you can ignore it. If it isn't then you can't...

-MM

---

From: Richard Shockey <[email-masked]>
Date: Fri, 11 Aug 2000 16:58:58 -0500

>If its there you can ignore it. If it isn't then you can't...

Chair hat off ... I pick a (a)  for Mike's specific reasons.

Chair hat on again... It is regrettable but understandable that we are, 
once again, at this late stage and have these issues come up.

The issue is then what is the manner by which dialing plans other than e164 
can be identified and does the use of '+' in the current expression 
preclude any future extensions in such a manner that the core protocol 
becomes essentially useless to implementers.

Does this meet the definition of a "showstopper" that would bring the 
document back from the IESG for some additional review and comments.

In the first place lets remind ourselves what this document is about.

##########

Title                       : E.164 number and DNS
         Author(s)       : P. Faltstrom
         Filename        : draft-ietf-enum-e164-dns-03.txt

This document discusses the use of DNS for storage of E.164 numbers.

###########

1. The draft under discussion is _not_  about the use of DNS and generic 
numbering/dialing plans public or private.  Therefore the use of the '+' is 
both useful and correct within the context of a document that is focused on 
the e.164 namespace and follows ITU guidelines on expression.

2. Do we need work on DNS and other numbering/dialing plans?   Obviously 
yes but I submit that e164-dns-03 is not the document to do that.  We 
clearly have need for such work and I think it is reasonable and 
appropriate that it be added to our work list in the upcoming months and 
added to our goals and milestones.

3. This is a proposed standard and not a draft standard.  We are all 
familiar with the process that defines how a protocol moves from proposed 
to draft based on actual implementation experience. I'm suggesting that we 
need to move forward in that direction _now_ with all deliberate speed.

Quite often in the IETF we define a proposed standard only to find out very 
very quickly that it does not meet all of the necessary criterion for wide 
scale deployment. In my personal experience the situation with Internet Fax 
standard RFC 2305 (Simple mode) eventually leading to RFC 2532 (Extended 
mode) offers a limited example.  The debate surrounding 2305 was quite 
difficult, consequently areas of the document were left deliberately 
ambiguous or cut out in a wholesale manner until the very shell of a 
protocol was left.  In fact that is what we have done here with Patricks 
draft during the past year.

Does the use of the "+" in the regexp preclude any future resolution of 
this issue?  Does
it exclude other ways of extending ENUM in the future?

IMHO ..No.  I have not seen one argument that states that keeping this 
requirement in would totally preclude, in the future, the use of some other 
form of expression to achieve the desired goal of number plan 
identification, such as the use of the service selector.  If you don't want 
to use the '+' in the future fine ..ignore it ..but by itself  it _might_ 
be expanded to accomplish the desired goal.  Operational experience should 
decide whether this is redundant or not. This should be the goal of 
_future_ work not the current document.

That will be my recommendation to the AD's.

Richard Shockey
Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W.
Suite 550
Washington DC. 20005
Voice 314.503.0640
Fax to EMail 815.333.1237 (Preferred for Fax)
DC Number 202.533.2811
INTERNET Mail & IFAX : [email-masked]
or   [email-masked]
http://www.neustar.com

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Hong Liu <[email-masked]>
Date: Fri, 11 Aug 2000 19:32:42 -0400

Richard, Patrik and others,

I am in favor of moving this document forward, though I have concerns about how
the current design choice may impact future extentions.

From the discussions surrouding the inclusion/exclusion of '+', I recognize the
need for a generic mechanism that includes both the numbering plan hint and the
service selector. The two proposals are in fact complementary to each other. In
the current document, E2U is defined exclusively for E.164 to URI mapping. If we
are to use the same algorithm for non-E164 numbers, such as national or corporate
dialing plans, we need to define new service selectors for those as well in order
to be semantically consistent.

If we are to adopt the 'numberplan+digits' as the generic structure for ENUM-like
Application Unique String, then for E.164, I suggest we do it all the way, such as
'e164+digits' as the input string to NAPTR. If we decide to use '+' as it is, then
I suggest that a paragraph be added in the document clarifying the semantics of
'+' as a numbering plan indicator.

Just my suggestion as an alternative to the inclusion/exclusion of '+'.

Regards,

--Hong

---

From: Richard Shockey <[email-masked]>
Date: Fri, 11 Aug 2000 19:24:50 -0500

>the current design choice may impact future extentions.

So do we all but as I think I made clear ..we have not created something 
that is cast in concrete. These are excellent points you have raised here, 
much appreciated and central to the ongoing process of protocol development 
beyond _proposed_ standard. Its just unfortunate that we're having this 
discussion at this point in time.

>to be semantically consistent.

Agreed...

>'+' as a numbering plan indicator.

Lets assume, for purposes of argument that '+' remains for the time 
being.  Is there any language you'd like to suggest here... about the usage 
of  '+'  ambiguous or unambiguous but leaving the door open for 
enhancements in a future ID, which I'd hope you'd write? :-)

Richard Shockey

---

From: Hong Liu <[email-masked]>
Date: Fri, 11 Aug 2000 23:50:39 -0400

Richard, Patrik, and others,

Thanks for the nice comments. I personally learned a lot from the email
exchanges in the last few days. Assuming that we will leave '+' as it is in the
document, then I would like to add a note at the end of the ENUM procedure,
i.e. Section 2, as something like the following:

"Note: The output of Step 2 above, i.e., an E.164 number without any characters
but the leading '+' and digits, is the input string to the NAPTR algorithm. The
leading '+' is the E.164 numbering plan indicator, which SHALL be used in
conjuction with the service selector E2U defined in Section 3.1.2 in all NAPTR
resource records with a non-empty service field for E.164 to URI mapping.

Other numbering plans MAY make use of the ENUM procedure defined above for
telephone number to URI mapping with the following modifications:
- Specification of an unique numbering plan indicator other than '+';
- Specification of a service selector other than 'E2U';
- Specification of the root domain name other than 'e164.arpa';
However, these specifications are outside of the scope of this document. It is
envisioned that other numbering plan indicators and service selectors will be
defined in a future document to accommodate multiple numbering plans using the
same ENUM mechanism. "

The language above is rough, as they are coming out of the top of my head.
Please feel free to make modifications as you see fit.

Not that I am stubborn, but I do feel that if we are to define
'numberplan+digits' as the generic structure for the input string to NAPTR, it
is better to change '+digits' to 'e164+digits' _now_ than later. I am more
concerned about the massive number of NAPTR RRs to be populated in the DNS
databases after this document becomes an RFC. As we have already seen, the
input string format does dictate the regexp format in a NAPTR RR. Why is it so
difficult to change? Anyway, I will accept the consensus of the group.

> enhancements in a future ID, which I'd hope you'd write? :-)

Sure, I will write an ID addressing extension issues for the next IETF meeting,
with some other folks who are interested in this topic.

Regards,

--Hong