Re: Send-N draft: draft-bellis-enum-send-n-02 published

On 30 Jun 2008, at 17:27, [email protected] wrote:
>> Inter-digit timeouts, as far as I understand, would bite the  
>> dialing customer
>> at the end of their dialing process because only after the timer's  
>> expiration
>> would the full number be submitted to the ENUM lookup mechanism.
>> But since the human can't dial at light speed - where's the gain in  
>> terms
>> of latency over just querying after each digit pressed?
>
> Yes, for the user it's the final digit time-out.  When should the  
> switch
> decide "enough is enough, it's time to try an ENUM lookup"?

For a human user manually entering a telephone number into a  
traditional handset there's going to be a minimum practical dialling  
time (approximately 2-3 seconds) following which a further delay of up  
to 2 seconds is going to be perceptually bearable. The acceptable  
dialling time is reduced if automation is part of the process, but as  
long as the call is being placed on behalf of a human those couple of  
seconds to connect the call are the primary differentiating element  
between 'good' and 'lousy' service levels.

Of course there are also use cases where a human intermediary is  
connecting the call (PBX or Telco operator assistance or Emergency  
Service) where the resolution of the second leg has to be perceptually  
near-instantaneous to match user expectations but I don't know enough  
about the interplay of ENUM with those services to comment on their  
relevance to this discussion.

>> Apologies.  NAPTR is becoming the TXT RR for enum; everything can  
>> be put
>> in there so conveniently, especially using "data" type URIs.   
>> That's not
>> what NAPTR was designed for.  And the fact that NAPTR is asked for  
>> and
>> thus this metadata can be sent by way of NAPTR appears more a bug  
>> than a
>> feature to me.
>
> Ah, yes.  I was advised that the "pstndata" Enumservice and URI  
> scheme had
> been devised specifically to mitigate the way that people were  
> making up
> arbitrary "data:," URI formats or otherwise sticking stuff in TXT  
> records.
> Hence why this draft draws on Richard's stuff in the CNAM draft.

Storing significant volumes of data directly in NAPTR records as as  
unwieldy process as doing the same with TXT records thanks to TTLs and  
payload limitations. Where NAPTRs do shine though is in providing  
public APIs via URI rewriting for RESTful data services, but that's a  
whole different discussion.


Ellie

Eleanor McHugh
Games With Brains
[email protected]