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

Send-n is not implemented in the enum client.

Implement something else (i.e. a client to another database which has length
information) in the same server.

It's possible that we'll decide the protocol for this new database is DNS.
I have no opinion on that yet.  I have an opinion that we should have a
database with length information that all services, and all devices, can
make use of.  Send-n is too limited, in my opinion.

Brian



> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, June 24, 2008 12:11 PM
> To: Brian Rosen
> Cc: [email protected]
> Subject: RE: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published
> 
> > The solution to the looking forward problem is easily applied to the
> looking
> > backward problem.
> >
> > If the proxy controlling the dialing for an old device has access to the
> > same data the new device that is controlling the dialing has, then the
> > problem is solved.
> 
> I don't follow your reasoning.  The soft switch I described doesn't have
> internal number length information, it only has a DNS interface to an
> ENUM-like database tree.
> 
> This isn't hypothetical, BTW.  It's how the UK's number portability
> solution is expected to work.
> 
> > The send-n solution isn't applicable to a device with a SEND button in a
> > sensible way.
> 
> Yes, that's correct.  It's not supposed to be.
> 
> Ray