Subject: AW: [Enum] enumservice field discussion

From: Brandner Rudolf <[email-masked]>
Date: Thu, 30 May 2002 03:59:19 +0200

Rich,

thanks for your comments, mine are inline...

> -----Ursprüngliche Nachricht-----
> Von: Richard Shockey [mailto:[email-masked]]
> Gesendet: Mittwoch, 29. Mai 2002 22:37
> An: Brandner Rudolf
> Cc: [email-masked]
> Betreff: Re: [Enum] enumservice field discussion
> 
> 
> 
> >
> >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?

Isn't that what ENUM is all about? I have a phone number and I want to know all means of communication associated with this phone number the domain holder is willing to reveal. At least, that's my view of what ENUM is and I might be off some miles here.

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

... or maybe .only. telfax? It looks like there might not always be one and only means of sending a fax.

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

I am here with you. However, my PC has a FAX software on it and is directly connected to my ISDN PBX. So sending a FAX I have the choice (and I personally like choices) to dial a number (might be an international one) to send the fax in case of telfax. Or I could dial up the local access number for my ISP and send the fax via e-mail in case of mailtofax.

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

You are absolutely right, and D3S is throwing away some (useful) of them because I had to decide beforehand what protocol to use. Or I KNOW beforehand what means of communication are associated with this phone number.

If I don't know it beforehand, I or my app needs to make a guess. mailtofax might probably be a good start querying ENUM. This query gives me all NAPTR records. What if it turns up nothing because there is no NAPTR with enumservice mailtofax? Then I or my app will have to make another guess: telfax perhaps. This query gives me all NAPTR records, again. Well, you get the picture.

We have to make a decision one way or the other. This decision has implications on the clients, network and the ENUM servers. My concern here is, that we might get to a consensus based on 'dislike' or 'unacceptable' whithout having looked at the implications more closely or whithout good reasoning.

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

I assume that you are thinking about grouping enumservices. Yes, this is another implication we need to look at.

To me, it looks like this is at least a two dimensional space. One dimension is the protocols to be used (which then lead to the associated URI), the other dimension is the function you can perform. This gives you a matrix of combinations and two possibilities of grouping. As an example (I am using  some high level enumservices Lawrence proposed for this example and some URIs), which is not exhaustive:

FUNCTION
--------
:
:
--------+------+------+-------+---------+-------+------+--------
talk    |  *   |  *   |  *    |  *      |       |      |
--------+------+------+-------+---------+-------+------+--------
srs     |      |  *   |       |         |       |      |
--------+------+------+-------+---------+-------+------+--------
deliver |  *   |      |       |  *      |       |  *   |
--------+------+------+-------+---------+-------+------+--------
        | tel: | sip: | h323: | mailto: | http: | ftp: |  ......  URI
                                                                  ---

The question you raise here is, which way is better for grouping? Either proposal has implications on this, too.

Actually, I did not do the combinatory stuff on this yet. Thus I am not sure, that there is a more optimal grouping or whether it is just mood because it is all the same, regardless which way you look at it.

Hope this helps,
Rudi

> snip...

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