Subject: [Enum] Triggering ENUM Queries

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 30 May 2002 10:55:29 +0200

Hi folks, good morning,
Rich wrote in response to Rudi:
 
> Should't you assume that you or your applicaiton knows what 
> enumservice its 
> looking for before it querys DNS? You have preselected fax ? 
> Or are you 
> saying ..oh I want to query DNS BEFORE I send a message 
> create a session to 
> see what my options are?

I think we have a point here, why there are different camps:

Camp B is assuming, that the ENUM query is launched from within an
application which already nows what it is looking for, so there should be an
efficient way to find out the ONE useful NAPTR (from the enumservice field).

Camp A has a broader view and see in addition the user who just wants to
communicate with another user and has not decided yet, how he will do this.
So the user is querying ENUM, retrieving all NAPTR records e.g. by a
stand-alone application, and gets the result displayed in a user meaningful
format, e.g. URLs sorted by tel, fax, sms, mail, like on a business card.
The user is now selecting the proper appclication by clicking on the URL.
This also explains, that this camp has no problem with peeking ahead beyond
the enumservices field.

To summarize, we really have three principle ways to trigger an ENUM query,
and we want to use the trials to find out the user preferences (maybe all
tree variants are needed anyway):

1. Stand-alone ENUM Client:

The stand-alone ENUM client is given an E.164 Number in the format +431...,
retrieving all NAPTRs (and ev. other records) from the given domain and
displaying them in a human readable and grouped form, eg.

Richard Stastny
Currently at the IETF in Yokohama

To talk: sip:user@host
To send a fax message: tel:+431...;svc=fax
To send an e-mail: mailto:user@host
To send an sms: tel:+43664...;svc=sms
To look on my webpage: http://www.stastny.com

Note that the additional text may come from TXT records

The user may now select the way to communicate, eg. he may first look up the
webpage (first choice for if you want to communicate with a company). If he
has no sip-client, he cannot talk.

It is obvious, that the above information is preferably in the following
NAPTRs:
NAPTR blabla "E2U+talk" blabla sip:user@host
NAPT blabla "E2U+msg" blabla tel:+431...;svc=fax
NAPTR blabla "E2U+msg" blabla mailto:user@host
NAPTR blabla "E2U+msg" blabla tel:+43664..;svc=sms
NAPTR blabla "E2U+info" blabla http://www.stastny.com

I agree, that I can create the same information from the enumservices
sip(voice), telfax, mailto, telsms, info.

2. ENUM queries from specific applications

If I have my fax-client or sms-client already started, and enter +431... in
the To field of my fax client, it is obvious, that I want a 'msg' service
with svc=fax (so I have to peek ahead) or 'telfax' or ?. So the application
is launching an ENUM add-on, querying ENUM DNS and replacing the entered
phone number with the URI retrieved from ENUM (similar to Outlook, if it
replaces a contact name entered).

Sip and tel are special in both cases:
Sip may be used for additional services than talk, but tel may also be used
by sip, if your service provider allows you to INVITE E.164 numbers (has a
gateway).

Anyway, I have to admit, that the camp B proposal is more straightforward
for this requirements. In response to Rich: In this case I suggest to have
both sip AND sipvoice AND sipwhatever. Sip only means, that you should
negotiate the services (except for services already listed in other NAPTRs).

Note: As one sees, I try to avoid the usage of order and preference. Order
IMHO shall not be used (currently) within the ENUM system at all, with
preference I am not sure yet. Maybe the trials will show.

3. ENUM query triggered by URL

I also see a third possibility to launch an ENUM query: by clicking on an
URL on a webpage or in a document. This is a bit different from the usage of
URL in the stand-alone client, because then I use the URL AFTER the ENUM
query. The problem here is, that this requires some additions to the
existing URI schemes, eg: 
mailto:+431... or sip:+431... or http://+431...

If there is an ambiguity, whether ENUM should be queried or not, a ;svc=enum
parameter could be used.

If such an URL is used, the corresponding application should be launched
and, provided there is an ENUM add-on, ENUM should be queried, and the
number should be replaced with the retrieved URI as in 2.

Proposal of a new URI scheme enum:+431...

This leads to another requirement: If a user has an ENUM entry, it does not
make sense to list all the different URLs e.g. on his e-mail signature,
pointing to the same ENUM entry.

He may just want to say, hey guys, I am in ENUM, you can get all information
there. Therefore a new URI scheme is required: 
enum:+431...

This URL would launch the standalone client from 1. and I can also imagine,
that a bubble with the information pops up, if you hoover with the mouse
over the URL ;-)

The new URI scheme ENUM may also come in handy to forward the complete E.164
domain to another number, including all services.

If I enter in my office number domain +4317978032

NAPTR blabla "E2U+enum" blabla enum:+436644204100

I can forward now ALL services to my mobile number, having all records in
one place. This is proposed as alternative to the use of CNAME for End
Users.

Note: For forwarding of voice calls only the usage of tel: was proposed.
This is IMHO problematic for different reasons: 
DNS is not designed for (too) dynamic updates anyway, 
forwardings should be done with the personal user agent of the provider,
It may be confusing to the user, if he has differnt forwardings on his GSTN
line and on ENUM, and these fwds are not synchronized.
And last but not least, the construct is ambiguos: if you retrieve a
tel:+431..., should you use this to establish a connection to the GSTN
directly via a gateway, or launch another ENUM query (thsi could be solved
also with the svc=enum parameter)

Best regards
Richard

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 30 May 2002 10:45:22 +0100

> efficient way to find out the ONE useful NAPTR (from the enumservice field).
[...]

A DNS query is going to return all the records no matter what, isn't it. So
we should perhaps be looking at minimizing the size of the NAPTR record.
This would imply that the service field should not duplicate anything
that's available in the resulting URL. It seems to me that this is more
important than reducing the processing time slightly.

Is there any way we can modify the specification of the REs to make it
easier to determine what protocol is used ? I don't mean replacing the
RE by something else, but an idea like "if the RE doesn't rewrite the
protocol field of the URI, the RE delimiter is '!'; if it does, the
delimiter is something else". Would this help ?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change

---

From: Michael Mealling <[email-masked]>
Date: Thu, 30 May 2002 10:31:04 -0400

> 3. ENUM query triggered by URL

IMHO, the first (or Camp A) should be a service in Camp B. If you simply
willy nilly show the user all NAPTR records regardless of any priority
settings or inquiry-style referral (e.g. LDAP or SIP) then you're
doing something that isn't explicit and is prone to confusion. You're basically
negating the ability to use preferences at all by ignoring them and showing
the user _everything_ regardless of whether or not the user should even
be seeing it.

IMHO, if you need to do #1 (don't get me wrong, I think its a cool application)
then I think you need to specify that information behind something that
can express policy and do it as an explicit query. I guess my problem with
the scheme you suggest in #1 is that "ENUM is used for turning an E.164
number into a URI", not advertising service endpoints intended for a user
interface. I realize the distinction is subtle but its an important one 
(especially when you throw in the mention of "additional text can be returned
in TXT records". Does that mean I can put logos and pop up ads in there too?)

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net