Subject: [Enum] I-D ACTION:draft-brandner-enum-tel-00.txt

From: [email-masked]
Date: Wed, 27 Feb 2002 07:22:48 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: 'The ENUM 'tel' enumservice'
	Author(s)	: R. Brandner, L. Conroy
	Filename	: draft-brandner-enum-tel-00.txt
	Pages		: 11
	Date		: 26-Feb-02
	
This document describes the enumservice 'tel' and how it is used with an
ENUM application when indicated within a returned a NAPTR record. It
gives guidelines for the treatment of records having this sub-field
value, and for the onward processing of information gleaned from the
enclosing NAPTR record.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brandner-enum-tel-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-brandner-enum-tel-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-brandner-enum-tel-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 28 Feb 2002 10:41:45 +0100

Hi Rudi,
here they are:
I have some comments to your draft-brandner-enum-tel-00.txt:

In Section 3.  'tel' sub-field definition it is stated:

_When used with an ENUM application, a NAPTR record including the 
indicator 'tel' in the enumservice sub-field implies that the
URI can be treated as formatted according to [9], and includes a
telephone number. This implies that the communications service described
by this record will require a telephone connection to be made._

The last sentence implies, that _in any case_ a client taking this NAPTR
record into account needs already a subscription to a Service Provider
providing access to a telephony service based on E.164 numbers natively. If
not, the E2U+tel service shall be ignored. My carefull wording should
induce, that the service provider not necessary need to have a gateway to
the GSTN, but in most cases this may apply. But since E.164 numbers may also
terminate on IP, this is not restricted to GSTN only. I also assume, that
the phone number supplied should different from the original AUS, because
this would create a loop in the first place.

So the primary use of tel is to point the client to another number then the
original AUS for some reason, if he intends to make a phone call to the GSTN
anyway. Possible applications I see is e.g. Freephone and NP services, i.e.
replacement of simple IN services.

IMHO the last sentence also implies, that a _telephone_ connection SHALL be
made in any case (not a voice connection).
 
I am now coming to section 4.3 Use of tel for Redirection Services. First, I
do not see much sense to point to much around anyway, with the danger of
creating loops. My second point is: What happens, if the redirected to entry
does not contain a tel service? Is than a other voice service to be used, or
is the last tel service to be used to make a telephone connection?

My proposal is: If the full ENUM entry is redirected to another E.164
number, CNAME shall be used. The tel service shall be used only to force a
call via the phone network, that is, using the E.164 number supplied, if and
only if the client has access to the phone network. This implies, that no
additional query is made to ENUM for the number provided by the tel service
from THIS client. This does not prevent another client (e.g. the client of
the used phone service provider) to query ENUM again (getting an answer or
not).

A compromise between the two views would be to provide an indicator in the
regexp, to indicate if the retrieved tel: is terminal or onother regarding
another ENUM query may be made. How to do this I leave to the experts of
regexp, because I am not.

I have two additional problems:

1. Section 4.1 Locality of the caller

the phone-context=+1 parameter SHALL not be used in ENUM (public ENUM) in
any case,

although I see the usability in private ENUM applications.

2. Section 4.2 TSP parameter.

I have some problems with the TSP parameter. First the SHOULD should be
definetely MAY.
The other implicationes definitely require more study, because in the GSTN
there may be carrier selection by the calling party, but the implications on
routing on the GSTN if the calling party or the transit network know the
destination network are to far reaching to be answered immediately. Also
there has to be some standardisation on the information retrived.

best regards
Richard

Richard STASTNY
OeFEG
Arsenal Objekt 24
P.O. Box 147
A-1103 Vienna, Austria

Tel: +43 664 420 4100
Fax: +43 1 79780 13
[email-masked]
[email-masked]

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