Re: Send-n, rat holes and real issues

Rosbotham, Paul wrote:
> LOL, you're learning.  I went through similar angst trying to prepare the NICC number length guidelines document I referenced earlier in this thread.
> 
> I think you missed that there are a couple of hundred assorted ranges in S=1 (ie +44 1) which are of 9 digit length, and even a couple at 8 digits.  Also, specific ranges in S=8 (ie +44 8) which are 7 digit (e.g. (0)800 1111 is our child helpine).  NB as Clive said, when I say 9, that's 11 in international form (inc 44).
> 
> What you're looking at is the supposedly authoritative source of data.  Better info can be found, but only by talking to the individual CPs...of which there are currently 384, off the top of my head.  That's what we're trying to get away from.
> 
> The point of Send-N is that the records are set according to what's populated into ENUM.  
> 
> - In the context of our porting database (ie a private ENUM), current plans are that it would be populated with all numbers hence Send-N would reflect the true structure of the numbering plan.  
> - In the context of user-ENUM where population is inevitably partial, then Send-N would reflect what's in there...e.g. if +448001111 wasn't populated, then no Send-N records would reflect its existence.  That's the point that Jay's been trying to get across...in a user-ENUM context the number lengths as specified by the numbering plan administrator are of limited value...e.g. if there was a range in the UK that was 15 digits long, coding that into Send-N in ENUM is pretty pointless unless any such numbers were actually populated in ENUM.

That is the most pointless thing I have ever heard of.

I think we're all agreed this information would be good if it were to be
made available in a useful form, now you're saying the information will
only be partially available if there is a NAPTR record, but if one or
more NAPTR records exist for a end user record then there is no need for
send-n, what the ????

-- 

Best regards,
 Duane