Subject: Re: [Enum] The use of "service type" and "subtype" fieldsin ENUM record

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2006 09:26:37 +0100

Also, note that the DNS query is still for a specific owner, which  
imply your resolver will most certainly cash all NAPTR records even  
though your "ENUM resolver" will only return a subset of the NAPTR  
returned (given the TTL is large enough).

So, if you have to issue a new query to the "ENUM resolver", that  
should not imply as heavy work as the previous query.

    paf

On 16 jan 2006, at 12.36, lconroy wrote:

> Hi there,
>  filter design depends on what you want to do. If the ENUM client  
> is in a
> voice gateway, then it's fairly simple.
>
> NOTE: The following is just an "Implementation description". There are
> many ways one could process the NAPTRs - this is just the way WE  
> did it
> in the U.K. trials.
>
> ----
>
> In our systems, we used the "simple" pattern matching scheme  
> mentioned in
> the "Experiences" draft to handle both RFC2916-style and RFC3261- 
> style NAPTRs.
> [Tokenise services field on '+' character, expect (and remove)  
> token "E2U",
> then process the rest].
>
> If the client has communication systems that can provide a given  
> teleservice
> (like voice) then that will be included in the filter - IMHO, this  
> must be
> more flexible that an explicit string match against "voice:tel".
>
> We sub-tokenised each Enumservice on ':' character, "cheated" by  
> creating a
> protocol sub-token for those Enumservices where it is implicit  
> (H323, SIP) and
> re-wrote the RFC2916-style "ldap" and "mailto" services into  
> "ldap:ldap" and
> "email:mailto", then pattern matched the generated list of  
> "published services"
> against the capabilities of the client.
>
> Our clients could handle voice, so we matched against {voice:tel,  
> sip:sip}
> (and voice:sip, as we were using TS 102 172 as well as the IETF/ 
> IANA services).
>
> For messaging, we matched against {{email:mailto, sms:mailto,  
> mms:mailto,
> ems:mailto} and {sms:tel, mms:tel, ems:tel} and {fax:tel}}, which  
> triggered
> one of three external communications programs - we did not have a  
> program
> to support ifax:mailto, so just pattern matching against {*:mailto}  
> would
> not work.
> For mobile clients with no email, SIP or fax support, we just  
> matched against
> {voice:tel} and {sms:tel, mms:tel, ems:tel} to run the voice or  
> text features
> of the phone.
>
> This worked well, but as you say it does require some processing to  
> get NAPTRs
> and their services field into a single list of "all teleservices  
> supported".
> The capabilities of the client devices was fixed so we could have  
> "hard wired"
> the "local support" match lists - however, we wanted the user to be  
> able to
> "switch off" sending an SMS/MMS/EMS message - this just consisted  
> of removing
> those items {sms:tel,mms:tel, ems:tel} from the "locally supported"  
> list.
> ----
> To summarise the steps:
> -  process the NAPTRs to generate one list of "published services"  
> of the form
>    <teleservice>:<protocol>
>
> -  match this against a list of "locally supported services",  
> ordered according
>    to the user's choice (e.g. voice first, then message using  
> mailto, then
>    SMS/MMS/EMS message, then fax)
>
> -  generate a list of "successful" matches, with a pointer to the  
> NAPTR(s)
>    that held the service and to the local program that needs to be  
> run.
> ----
> As a final note - we kept a "winning list" rather than a single  
> answer so
> that, if the first choice failed, the ENUM client could try the  
> next without
> re-processing. This worked as the TTLs on the NAPTRs were a few  
> minutes
> - if the NAPTRs had very short TTLs (e.g. 1 second), this would not  
> have
> been valid.
>
> I hope this helps,
>   Lawrence
>
>
> On 16 Jan 2006, at 10:19, chenhui wrote:
>> Hi all,
>>
>> We are considering how to implement ENUM resolver into current  
>> communication clients or service systems.
>>
>> Now most of current communication applications do not support ENUM  
>> resolution, although ENUM records can be retieved by "nslookup" or  
>> "dig" query "NAPTR" resource records, different clients or service  
>> systems can not support all returned results. That is, some  
>> records are useless for specific services. Also, too many useless  
>> records will affect service performance.
>>
>> Using filter is a useful method to resolve this problem. To use  
>> "service type" and "subtype", only valuable results can be returned.
>>
>> But, we are not sure how can make the ENUM resolver works more  
>> reasonable. Because exact "service type" and "subtype" will filter  
>> many results, including of old "service type". For example, there  
>> is an ENUM number having NAPTR records of "E2U+email:mailto", "E2U 
>> +sms:mailto", and "E2U+ems:mailto", if the filter is "E2U 
>> +sms:mailto", it just returns NAPTR records with exact "service  
>> type" and "subtype". Or if there is no any corresponding record,  
>> this call will be failed. Too much failure will affect service  
>> performance.
>>
>> Another way is to support not exact filter, like only by  
>> "subtype". The ENUM resolver can return all relative records of  
>> "E2U+email:mailto", "E2U+sms:mailto", and "E2U+ems:mailto".  
>> Application clients or service systems can automatically choose  
>> its perferred results. However, this may introduce more service  
>> delay.
>>
>> What is the best way? Do you have any suggestion on this problem?
>>
>> BTW, We find that IANA has published ENUM services on Jan 10th, 
>> 2006. The webpage is http://www.iana.org/assignments/enum-services
>> _______________________________________________
>> enum mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/enum
>
>
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

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

---

From: "chenhui" <[email-masked]>
Date: Thu, 16 Feb 2006 10:37:11 +0800

We agree the two issues about ENUM resolver, the first is ENUM resolver just returns some special results to the terminal as needed and this function should be implemented in a simple way, and the second is ENUM resolver needs no cache because local DNS resolver can cache the records.

And it is just the rule we abide by in China ENUM trial.

chenhui

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 16 Feb 2006 08:29:32 +0100

On 16 feb 2006, at 03.37, chenhui wrote:

> and the second is ENUM resolver needs no cache because local DNS  
> resolver can cache the records

But IF it is caching, it definitely (like any receiver of DNS data)  
must look at the TTL on the data.

    paf

---

From: lconroy <[email-masked]>
Date: Thu, 16 Feb 2006 11:57:59 +0000

Hi Patrik, chenhui, folks,
   Agreed that the DNS resolver will cache results, so a subsequent  
DNS query for the same domain/owner will be MUCH quicker.

However, **in our client**, we did not perform a second ENUM query if  
the "winning" URI fails (e.g. a telephone number returns busy).  
Carrying out another query would just return the same winner - the  
telephone number that was just busy.
Instead, **in our client**, we keep an ordered list of winners, and  
try the "next one" in the list if the first one fails.

This is just the scheme we used in our client in the UK trial - it is  
in no way part of the ENUM standard, and it may not always be  
appropriate behaviour.
It worked in our case as the TTLs on the NAPTRs was long, so the  
"winners list" was still valid when we tried the next contact

all the best,
   Lawrence