Subject: [Enum] enumservice field discussion

From: Brandner Rudolf <[email-masked]>
Date: Wed, 29 May 2002 18:48:02 +0200

Hi all,

I had a bad vacation (only rain) and I'm having a bad e-mail day, too. Just coming back from vacation and digging through the enum mailing list I got more and more confused.

In order to be able to start trials we need to sort out what the enumservice field should contain and what not. Then we can put that down into the docs to which the trials can refer.

Having read the threads it looks to me that there are two camps:

Camp A: proposing high level enumservices like talk, msg, etc. From an end systems view, this is fine with me. If I want to talk to someone, I am interested in URIs enabling me to talk to someone. Or if I want to deposit a message, I am interested in URIs to do so. If my end system gets URIs with protocols my end system is not capable of (false positives), it discards it.

Camp B: proposing to have hints on URI schema in the enumservice field for early discard of false positives (see Patriks e-mail about X >= Y etc...).

So it looks to me, that the whole discussion is going about when and where in the process of getting the URIs the false positives, if any, should be discarded. With Camp A proposal, this has to be done in the application (it knows what protocols the end system is capable of), with Camp B proposal it can be done within the D3S process (the enumservice field has tags or hints on the URIs it can deal with).

Now let's look at the cost side here. The Camp B proposal saves computational resources by discarding false positives before doing the regexp. On the other hand, has higher cost on network traffic. If I have a sophisticated gadget with all kind of protocols in it and I want to send a message to someone, the end system will have to call ENUM several times to collect all possible URIs for the protocols to send a message (i.e. SMS, EMS, MMS, SMTP, FAX, etc.).
The Camp A proposal collects all URIs for a given high level enumservice (i.e. talk, msg, etc.) by querying ENUM once, but potentially wasting computational resources by doing regexp on false positives.

Now my question here is, how can we solve this situation?

I, personally, are in favour on Camp A proposal, because I think (and history has proven it), that computational power of end systems is growing. So even some UMTS mobile gadgets will cope with this. Thinking of those UMTS mobile thingies, network resources are going to be scarce for quite a while in this arena, that's at least what I hear from the mobile guys.

I can survive the tel, telvoice, telsms, telfax, telyounameit hell, but would be somehow unhappy (if anyone cares ;^)

Patrik, Rich, Lawrence, Richard, your comments, please.

Rudi

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

---

From: Richard Shockey <[email-masked]>
Date: Wed, 29 May 2002 16:37:29 -0400

>
>Camp B: proposing to have hints on URI schema in the enumservice field for 
>early discard of false positives (see Patriks e-mail about X >= Y etc...).
>
>So it looks to me, that the whole discussion is going about when and where 
>in the process of getting the URIs the false positives, if any, should be 
>discarded. With Camp A proposal, this has to be done in the application 
>(it knows what protocols the end system is capable of), with Camp B 
>proposal it can be done within the D3S process (the enumservice field has 
>tags or hints on the URIs it can deal with).
>
>Now let's look at the cost side here. The Camp B proposal saves 
>computational resources by discarding false positives before doing the 
>regexp. On the other hand, has higher cost on network traffic. If I have a 
>sophisticated gadget with all kind of protocols in it and I want to send a 
>message to someone, the end system will have to call ENUM several times to 
>collect all possible URIs for the protocols to send a message (i.e. SMS, 
>EMS, MMS, SMTP, FAX, etc.).
>The Camp A proposal collects all URIs for a given high level enumservice 
>(i.e. talk, msg, etc.) by querying ENUM once, but potentially wasting 
>computational resources by doing regexp on false positives.

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?

A fax machine is going only for mailtofax or something like that.

My sip phone is only going to look for sip ... etc

Remember the DNS will give you back ALL NAPTR records on any query.

One other reason that I have dislike the discussion of all of these 
enumservice labels is that at some point you might break the UDP packet 
limit and force a DNS query via TCP, thus injecting more latency into the 
response.

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