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

["Wang Feng"<[e-mail]>]

hi Lawrence,

 What you have mentioned is a good method to resolve the asked question. 
 
 Not to return all records, not to return exactly pattern matched records, just to
 get back useful or recognizable ("local supported") service records.
 
 It's really very flexible, fitting for different level need.
 
 Thanks for your opinion.
 
  Regards,	

	Wang Feng
	[e-mail]
	2006-01-17


======= 2006-01-16 11:36:00 =======

>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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/enum
>




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