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

From: Patrik Fältström <[email-masked]>
Date: Wed, 9 Aug 2000 22:44:35 +0200

At 15.07 -0500 00-08-09, James Yu wrote:
>  > Yes. In a future version it _might_ be the case that we can have a
>>  similar function for a non-E.164 number. So we made the choice of
>>  keeping the '+' to signal to the regexp rewrite that we are talking
>>  about a "real" E.164 number, as you think.
>
>Don't know whether it is a good idea to mix real E.164 numbers and non-E.164
>numbers.  Non-E.164 (E.164 like) number can use something like pe164.  May
>be you are trying to use E2U for those numbers to avoid defining a new one?
>But see the reason below that there will be other "international" numbering
>plans that may use enum-like process.  So it would be fine to create a new
>"numbering plan" name for those non-E.164 numbers.  For that reason, I
>suggest that we don't add '+' for the NAPTR part of the process in
>e164.arpa/enum.

What I was thinking of was something which in the NAPTR recursive 
process was some way for the rewrite of the telephone number might 
rewrite a non-e164 number (without leading '+') into one which is a 
E.164 number (and vice versa).

I.e. I felt together with Ericsson people (and others) that it is 
important that you when defining the rewrite rule in the regular 
expression can write one which matches (or not) on only E.164 numbers 
or not.

I have no ide whether this will be used or not, but people have 
adviced me all along to keep the '+' if possible. Phone people that 
is.

>There may be other numbering plans that can use enum.  As indicated in the
>I-D on the "roam" service, cellular roaming actually requires mapping from
>E.212 (International Mobile Station Identification or IMSI) to URL(s) and/or
>from E.214 (Mobile Global Title) to URL in addition to E.164 to URL mapping.

A similar service can also use NAPTR in a similar way. I would not 
say "enum"...

>Since enum addresses E.164 only, so e212.arpa and/or e214.arpa has/have not
>been proposed to the enum group.  But the basic enum concept/process will
>apply to any other numbering plans that require mapping from a number under
>that numbering plan to URL(s).

Yes. I understand.

>Once enum process is stable, John Loughney,
>myself or someone else may start proposing e212.arpa and/or e214.arpa or
>some others using enum-like process.

Ok.

>  > No, I am talking about the "tel" resolution. Someone have to talk
>>  about how to resolv a tel: URI given that the ENUM algorithm exist.
>>  Note that this is just an example.
>
>I know the text is about the tel URL.  But the phrase is not clear.  Does it
>mean (the current text) that if tel URL is returned in the NAPTR record and
>the client decides to use it, the client will always (re-)start the enum
>process because the tel URL contains a POTS (E.164) number unless the POTS
>number is the same as the one used in the previous enum process (loop
>detected)?  That's the clarification I asked in the previous message.

It is intended to be unclear as noone have written/updated the tel: 
URI spec to define what path to take. Both are possible. I made the 
choice to NOT write about this in this spec. The tel: URI spec needs 
to be updated.

    paf

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