Subject: RE: [Enum] SchemaSet strawman

From: "Stastny, Richard" <[email-masked]>
Date: Mon, 27 May 2002 11:34:47 +0200

Hi Folks,

I am a bit confused with this discussion:

Patrik and Rich request more information from people which want
enumservices, and also they want to see a (draft) RFC for each enumservice,
but on the other hand each proposal coming in is either not fitting into the
D3S scheme or to ugly or to complicated;-)

As far as the proposals are concerned, we have on one extreme side the "sip"
group, which only needs "E2U+sip" and do not see any further need for other
enumservices, on the other side the "other URIs and services also group",
which see the thing more differentiated, thus ending up with every potential
service listed (and a lot of people between the two extremes).

If I add Patriks request, that an application needs to have all information
required to select a NAPTR in the enumservices field, the latter group seems
to be correct.

The problem I see here is, that we cannot use the service parameters as
proposed in section 2.4.2 of RFC2916bis:

service_field = [ "E2U" 1*("+" enumservice)] 

because we have different flavors of "enumservice"s.

If we use a scheme similar the one proposed by Michael:

<D3S-application-tag>-<enumservice-tag>+<URI-scheme>
Or
<D3S-application-tag> - <URI-scheme> 1*( + <enumservice-tag>) from Lawrence

this generic scheme NEED to be defined in RFC2916bis.

As long a this question has not been clarified, it does not make sense to
make any concrete proposals:

IMHO opinion we should first try to get the whole picture, like a common
consensus on how all currently envisaged service fit in this picture.

A good starter for this is the proposal from Lawrence:

'talk'/'phone' can use "sip:", "tel:", or "h323:".

'voice' might use "sip:", "tel:", or "h323:". This may be a pure 
subset of 'talk'

'video'/'see' can use "h323:" or "sip:" and might, I guess, use 
"tel:". Again, this may be a pure subset of 'talk'

'message'/'deliver' can use "mailto:", "tel:" with "svc=fax" or 
"svc=sms" or "svc=mms", or "sip:" (where this leads to a 
non-session-oriented IM message)

'file'/'info' can use "http:" or "ftp:" or "https:" or "sftp:" to 
indicate the address of the information in question. (I strongly 
expect this to be used mostly with "http:" to indicate the "home 
page" of the registrant).

'srs'/'inquire'/'enquire' can be used with "sip:" or with "ldap:". At 
present, we have the "sip-e164" draft to cover this one; someone 
needs to add thought to how "ldap:" or any other srs protocol might 
be used.

'chat'/'textchat' can use "sip:" (where this leads to a 
session-oriented IM exchange), "tel:" with "svc=tdd"

'streaming' can use "rtsp:"

'share' can use, I guess, "h323:" or "wb:" or possibly "sip:"

Plus the also proposed 'any'

To clarify: what is important here is not the names (chat or textchat), ii
is the semantic. I also agree with the statement, that we should avoid
duplicate names for enumservices, services and URIs, so no enumservice
should be named mailto or sip.

So I propose that we first agree on these generic enumservices scheme, and
than specific proposals may be forwarded by the specialists of the services
themselves.

Any proposed scheme must solve for example my problem:

I want to announce 3 services in ENUM: a phone, a fax and an sms enabled
number. There may be the two extremes and any combination between:

1. All services are on one E.164 number (e.g. a sms-enabled fixed number)
2. The services are all on differnt E.164 numbers, all with tel: URIs

Question:
How does the one? NAPTR record look like in the first case, and how does the
three NAPTR records look the second case. I a scheme does not solve this
problem, it is useless.

I also want to forward another problem we detected with defining the trials:
The definition of the enumservices is not only important for the client
applications resolving the NAPTR records, it is also important for the
user-interface for entering data to the DNS. This issue has never been
discussed, but we should keep in mind, that there has to be a web-portal
provided by the Tier 2 Name Service providers, which enables "normal" users
to enter their data to the DNS. Since we cannot expect the normal users to
be D3S and NAPTR experts, we also have to provide some "translation". How
does e.g. a user friendly webpage look for the above mentioned example. Does
the user have to know, how many NAPTR records have to be created for a give
combination?

Best regards
Richard  

Richard STASTNY
OeFEG/Telekom Austria
Box 147, A-1103 Vienna, Austria
tel:+43 664 420 4100
fax:+43 1 797 80 13
mailto:[email-masked]  

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 27 May 2002 13:32:27 +0200

> 2. The services are all on differnt E.164 numbers, all with tel: URIs

You use tel uri and nothing else. Then you probably need one enumservice
for the phone where you do voice, one for the tel uri where you do fax and
one for the tel uri where you do sms. Especially as they use different
E.164 numbers. So, for each number, you have one NAPTR which specify
whatever enumservice you define. If people need to differentiate between
tel uri for voice and tel uri for fax, then that needs to be in the
enumservicefield.

This is by the way I have heard.

If you used SIP instead, the sip people say that one URI is enough, and
negotiation is done inside the sip negotiation phase, so only one NAPTR is
enough which have one enumservice regardless of whether it is phone, fax or
pager.

I.e. we need MUCH more information from people which actually will use the
NAPTR. Technical information.

> Question:
> How does the one? NAPTR record look like in the first case, and how does
> the three NAPTR records look the second case. I a scheme does not solve
> this problem, it is useless.

As you have three different E.164, there will be three different NAPTR.

If you have one number which you publish which will lead to the three
different services, then you have three NAPTR aswell, each one of them via
the rewrite lead to a different tel URI. I.e. the final URI's people get
will be different. Have to be different.

> I also want to forward another problem we detected with defining the
> trials: The definition of the enumservices is not only important for the
> client applications resolving the NAPTR records, it is also important for
> the user-interface for entering data to the DNS. This issue has never been
> provided by the Tier 2 Name Service providers, which enables "normal"
> users to enter their data to the DNS.

I would never ever have "web" interface to a DNS I run! For security
reasons if nothing else.

> Since we cannot expect the normal
> users to be D3S and NAPTR experts, we also have to provide some
> "translation". How does e.g. a user friendly webpage look for the above
> mentioned example. Does the user have to know, how many NAPTR records
> have to be created for a give combination?

How the translation is to be done is up to the "enumserviceproviders". An
excellent for _NON_ standardization and instead competition can work.

  paf

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 27 May 2002 13:54:32 +0100

>  > 2. The services are all on differnt E.164 numbers, all with tel: URIs

<snip>

>  > users to enter their data to the DNS.

<snip>
To which I reply:
Hi Patrik, Richard, folks,
   To clarify, in case (2), there will be three NAPTRs as there will be three
domains (or CNAMEs plus a NAPTR). Each of the discrete (terminal) NAPTRs
will include a (regexp that will generate a) URI. The content of the URIs can
be the same.

(p.s. Re. security - 'web portal' includes https: I assume).

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 May 2002 11:42:19 -0400

>tel uri for voice and tel uri for fax, then that needs to be in the

Ah thank you Patrik ...yes    tel+fax , tel+voice , tel+sms , tel+tdd 
,etc.  This is clearly a case for differentiation or "granularity" in the 
description of endpoint PSTN services that for lack of a better label is 
defined as [ tel ]. Plus I think the argument could be made that the needs 
and requirements for this form of differentiation justify the exposure of 
the data in the global DNS.   I dont like it ...but if it is necessary then 
so be it.

>enough which have one enumservice regardless of whether it is phone, fax or

yes ...  and the analogy to this is PSTN fax itself where negotiation of 
capabilities [T.30] is "on the wire" and does not require user preselection

>I would never ever have "web" interface to a DNS I run! For security

Patrik I know what he means a user interface and a script that would 
ultimately through some security and validation means actually write the 
NAPTR record for the FQDN.  The desire is for users to actually create and 
control their ENUM services. Frankly I think its power user stuff since the 
vast majority of users IMHO will want some else (the service provider ) to 
do all of this dirty work and jsut make sure it works.

A similar problem statement would be  changing preference profiles is SIP 
through a mechanism that takes customer input and then writes the CPL 
script file at the egress proxy.

>excellent for _NON_ standardization and instead competition can work.

ditto exactly ... and N* has a couple of Perl script files that we've use 
on our web site to take user input apply some validation tests and then it 
generates the DNS entries for our test site.  Patrik is absolutely correct 
this is a fertile area for experimentation and competition.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<