Re: [Enum] Triggering ENUM Queries

[Michael Mealling <[e-mail]>]

On Thu, May 30, 2002 at 10:55:29AM +0200, Stastny, Richard wrote:
> 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.
> 
> 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
> 
> 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).
> 
> 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
[e-mail]      |                              | http://www.neonym.net

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