Re: I-D Action: New draft - draft-bellis-enum-send-n-00
Duane <[email protected]>
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <[email protected]> |
Lawrence Conroy wrote: > NOTE WELL - this has NOT changed the applicability text of 3761 at all. > Dialing Plans are specifically excluded from ENUM. Thus before the > esteemed SIP aficionados dive in, ENUM is about numbers, not dialed > digit strings. This is a little more grey then you seem to be painting, even if no dns checks are made until the full length is hit I see this as useful even for non-SIP/non-VoIP applications since in theory sending an email to a phone number and having the email application doing an enum lookup could do a check to see if the number exists and failing that could also check that the length is valid. > An ENUM client is also expected to make an ENUM query only where it > believes it has a complete E.164 number. RFC 3761 goes on to accept > that a client may not know what constitutes a valid E.164 number (some > of us call outside the NANP :). Some of us rarely call inside the NANP :) > However, it is pushing this a bit far to send out an ENUM query with a > partially collected number, in the expectation of getting back an ISUP > SND style response. This is not something the originating node > believes is a complete number - it's something it suspects isn't. Thus > whilst I really like the concept, I fear that ENUM is not the > appropriate carrier. As above only send out queries as necessary to verify the length is valid and I can see how this would be useful to all aspects of ENUM queries. I also agree that specifically in terms of SIP/VoIP it would be a bad idea and would create a lot of noise to send out numerous queries before the any inter-digit timeouts occur. Although if one thinks about it national dial plans rarely change, and the only exception here being the open numbering plan in Germany and Austria, so fixed numbering plans could in theory have relatively long time to live values to over come problems with noise/excessive queries. I will have time shortly to play further with this to see how it would effect other DNS entries and will comment more on the technical problems after that. -- Best regards, Duane