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

From: James Yu <[email-masked]>
Date: Wed, 9 Aug 2000 15:10:42 -0500

Patrik,

Please see the comments below.

James

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2000 3:10 PM
> To: James Yu
> Cc: 'enum'
> Subject: Re: draft-ietf-enum-e164-dns-03.txt
> 
> 
> At 09.00 -0500 00-08-09, James Yu wrote:
> >-  In several places, you mentioned that "An E.164 number, 
> without any
> >characters but leading '+' and digits, (result of step 2 in 
> section 2 above)
> >is the input to the NAPTR algorithm."   Since '+' has been 
> removed from the
> >E.164 number during the "enum process" of formulating the 
> DNS query, it is
> >not clear how this leading '+' in the original E.164 number 
> has anything to
> >do with the NAPTR algorithm during the DNS process.    I 
> have noticed that
> >you specified that the E.164 number if the form as specified 
> in step 2 in
> >section 2 is used as the first operand.  Is there a special 
> reason that the
> >leading '+' must be there?  Is there is a good reason (e.g., 
> to indicate
> >that it is an international number)?  It would be better to 
> discuss how to
> >formulate/recover the E.164 number from the DNS query plus 
> the leading '+'
> >without referring to the enum process if we are addressing the NAPTR
> >algorithm.
> 
> 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.

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.
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).  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.
 
> 
> >- Page 5, section 3.2.2, 1st paragraph, 2nd to the last line:
> >   Please clarify which procedure is restarted with this new 
> E.164 number.
> >Is it the enum procedure or is it the tel procedure?   I 
> guess that you are
> >talking about the enum process.  So if the tel URL contains 
> the same E.164
> >number, a loop is detected and the client will not repeat 
> the enum process.
> >But if the tel URL contains a different E.164 number, then 
> the enum process
> >will start again.  Or are you implying that the enum process will not
> >restart for any E.164 number in the tel URL?
> 
> 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.

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

---

From: Hong Liu <[email-masked]>
Date: Wed, 09 Aug 2000 16:24:28 -0400

Patrick,

I agree with James that the inclusion of "+" in the enum process is not
necessary. An E.164 number is a sequence of digits. "+" is only used for better
readability, just like "-" in between digits.

I will raise another point of "tel" URL in a separate email.

--Hong

---

From: Hong Liu <[email-masked]>
Date: Wed, 09 Aug 2000 16:30:32 -0400

Patrick,

I would like to raise a point about the usage of "tel:" URL in the context of
ENUM. In RFC2806, "tel:" URL also includes local numbers, plus other constructs
such as ISDN subaddress, post-dial digits, etc. Do you think it would be better
to include a sentence or two in your draft to restrict the usage of "tel:" URL
to only E.164 numbers in the NAPTR RRs?

--Hong

---

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

>readability, just like "-" in between digits.

"Other" people working with telephone numbers has told me that they 
want the '+' there to be able to distinguish between a number which 
is "converted" into a full E.164 number from a local one (in a closed 
numbering plan or such) and not.

For me, being able to know the difference seems to be "a good thing". 
And you have to have VERY strong arguments for _NOT_ have the '+' 
there, and not only "it is not needed".

>I will raise another point of "tel" URL in a separate email.

Ok.

   paf

---

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

>to only E.164 numbers in the NAPTR RRs?

No.

The use of tel: URI in the draft is non-normative as it is in an example.

I think RFC 2806 should be updated to make things more clear.

   paf

---

From: Hong Liu <[email-masked]>
Date: Wed, 09 Aug 2000 16:55:46 -0400

Patrick,

I notice that in Example 1 of the new draft, the protocol of the NAPTR RR for
email was changed from "smtp+E2U" to "mailto+E2U". I am wondering why it was
changed that way.

According to the definition of NAPTR, the service field is "protocol+rs". I am
not sure if "mailto" can be regarded as a protocol, unless my understanding of
"protocol" is wrong.

In a corridor discussion with Greg and Richard in Pittsburgh after the ENUM
session, we realized that the interplay between a protocol and a service is more
complicated than it seems. Basically, a protocol may enable more than one
service. For example, SMTP can be used for email, voice messaging and Internet
fax. Similarly, SIP can be used for VoIP calls and IM. The question is how we
can encode both the protocol and the service information, given the current
definition of NAPTR. It is obvious that some of the URL schemes used in ENUM are
not sufficient to convey the service intended. Is there any way out of this?

--Hong

---

From: Hong Liu <[email-masked]>
Date: Wed, 09 Aug 2000 17:35:28 -0400

Patrik,

Please see my comments in between lines.

--Hong

> numbering plan or such) and not.

I would like to hear what the "other" people say about this. It may help to
have an example to show why it is needed.

As far as I understand, ENUM is about mapping an E.164 number to a set of
URIs. The input to ENUM is an E.164 number. I don't know why and where
non-E.164 numbers come into play here.

> there, and not only "it is not needed".

The problem here is that I don't see any VERY strong arguments for having
the "+" there either. I remain to be convinced.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Aug 2000 07:21:23 +0200

>email was changed from "smtp+E2U" to "mailto+E2U". I am wondering why it was

Because people wanted:

  - The protocol specification should tell what protocol is in use.
    It should be possible to register "arbitrary such things" in the
    future, where more than one might use the same URI scheme.
  - URI schemes themselves can be used as protocols.

So, having a name as protocol in one example which is different from 
the URI scheme was very confusing.

>not sure if "mailto" can be regarded as a protocol, unless my understanding of

protocol can be whatever. It's just a textual string.

>For example, SMTP can be used for email, voice messaging and Internet
>fax.

Exactly.

>Similarly, SIP can be used for VoIP calls and IM. The question is how we

By writing a new RFC which defines new protocols in the E2U "rs" in 
the NAPTR in ENUM which talks about "sending a fax via email, i.e. 
sending fax using a mailto URI", "sending a voicemail via email, i.e. 
sending voicemail using a mailto URI" etc.

   paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 10 Aug 2000 07:41:34 -0400

> protocol can be whatever. It's just a textual string.

Correct. By 'protocol' we mean a way of doing things that is specific
to the Application. For example, in the URI Resolution Application we
created a protocol string called THTTP. THTTP (RFC 2169) is a profile
of how to use HTTP 1.1 for URN resolution. We decided on using the
string "thttp" as the protocol instead of just "http" since what you
need in this field is a protocol that is specific to your Application.
Just putting "http" or "smtp" in there isn't sufficient unless you
specify that you use the entire protocol "as-is". In the case of
ENUM this is 'ok'. In the future I envision a new document that
describes new ENUM specific protocol profiles such as "voicemail"
or "instantmessage" which then uses the URI scheme to specify exactly 
how that voicemail or instantmessage is sent.

> sending voicemail using a mailto URI" etc.

Yep....

-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]