Re: Send-n, rat holes and real issues

> 
> 
> Rosbotham, Paul wrote:
> 
> > ...the point is the Send-N records are populated according 
> to what NAPTRs *are* populated, not according to those which 
> could theoretically be populated.  In the latter example, 
> it's saying "don't bother querying me until you've got at 
> least 11 digits because there's nothing in ENUM with anything 
> less".  It's *not* saying "according to the numbering plan 
> administrator, all numbers in this range are at least 11 
> digits long".  Subtle difference.
> 
> That was my point, if there is NAPTR records present you want to
> supplement it with a send-n, but what's the point in that since the
> NAPTR record would be present anyway.
> 
> This is gone from wanting to know what prefix lengths are to 
> wanting to
> know when a NAPTR is present by having a second one for good measure.
>
 
Ok, I'll try one more time.

Let's say for the sake of argument that +448001111 isn't present, end-user is dialling : ultimately they're going to dial 0800123456 but so far they've only dialled 0800 and are dithering about what the next digit is.

If I query on 0.0.8.4.4.e164.foo I get a Send-N of 11.

In absence of Send-N records I get no information other than there's no NAPTR for that combination of digits.

With the Send-11, I know that when the customer dials "1" (recall I already have the 0800) there's no point in requerying.  Likewise when they dial 2.  In fact, I don't bother requerying until they've dialled 0800123456.  The query on 6.5.4.3.2.1.0.0.8.e164.foo provides the NAPTR.  It doesn't result in a Send-N.

Without the Send-11, with no knowledge of the numbering plan I'd query on 1.0.0.8.e164.foo, then 2.1.0.0.8.e164.foo etc.

Now, because there's a mixture of number lengths in +44800, if my user was instead dialing 08001234789 (ie in a range one digit longer), when I queried on the 8.7.4.3.2.1.0.0.8.4.4.e164.foo having collected 11 digits after getting a Send-11, it would result in another Send-N, this time N=12 because the extra information I've provided has pinpointed it to being a number in a longer range.  This assumes at least one of x.8.7.4.3.2.1.0.0.8.4.4.e164.foo (x=0...9) is populated...if it's not it's pointless me collecting an extra digit and requerying, because I'll still get no record for my query.

So, for numbering plans where no complete number is a prefix of another (*), you should either get the NAPTR per today, or a Send-N, but not both.

(*) I believe that in some countries that may not be the case, e.g. 01234567 and 01234567890 can exist as separate numbers...obviously there'd be issues in that scenario.


This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ