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

From: BARNOLE Valerie FTRD/DAC/ISS <[email-masked]>
Date: Fri, 11 Aug 2000 18:13:01 +0200

Hong,

I think that the "+" issue conveys the question of the openness of the ENUM
algorithm use.

Strictly speaking, if I consider that this algorithm only applies to E.164
numbers (CC followed by N(S)N), I agree : there is no use for step 2 of the
ENUM procedure, let's remove in one step all non-digits characters. So
there's only E2U. To be drastic, even from step 1, a number with "+" should
be considered as incorrect.

So it means to me that if another type of number(corporate number or
else)than E.164 is dialled, it has to finally result in an E.164 formatted
number to be handled through ENUM from step 1.
If not, it does not work. It may be a way to proceed but is it really what
we want ?
I see it difficult to solve by adding a new service code for every private
plan. So I do not see a way out of this either than considering only E.164
formatted numbers or adding a hint of the numbering plan (at least, keeping
the door open to give this hint by keeping "+" like it is by now in the
draft and maybe adding some words to justify).

In my view, you will find the same issue with another application (I do not
quote UPT2U, because UPT numbers are E.164 numbers under CC 878 and I do not
quote IMSI2U, because of the non-availability to the public of IMSIs for
fraud prevention reasons). Other ITU numbers or identifyers that might be
used are built on the E.164 kind of model, with "national like" part (like
after the MCC in the IMSIs).

So I would be in favor of keeping "+" but maybe I did not understand
everything.

end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole

FTR&D/DAC/ACE

tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

mail to : [email-masked]

-----Message d'origine-----
De: Hong Liu [mailto:[email-masked]]
Date: vendredi 11 août 2000 16:34
À: Patrik Fältström
Cc: Manfredi, Albert E; [email-masked]'; [email-masked];
[email-masked]
Objet: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt

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

Patrik Fältström wrote:

> 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):
>
> 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

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

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