I-D Action:draft-ietf-enum-3761bis-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title           : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)
	Author(s)       : S. Bradner, et al.
	Filename        : draft-ietf-enum-3761bis-03.txt
	Pages           : 22
	Date            : 2008-03-31

This document discusses the use of the Domain Name System (DNS) for
the storage of E.164 numbers, and for resolving them into URIs that
can be used for (for example) telephony call setup.  This document
also describes how the DNS can be used to identify the services
associated with an E.164 number.  This document obsoletes RFC 3761.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list

Protocol Action: 'A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services' to Proposed Standard

The IESG has approved the following document:

- 'A Telephone Number Mapping (ENUM) Service Registration for Internet 
   Calendaring Services '
   <draft-ietf-enum-calendar-service-04.txt> as a Proposed Standard

This document is the product of the Telephone Number Mapping Working 
Group. 

The IESG contact persons are Jon Peterson and Cullen Jennings.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-04.txt

Technical Summary

This document registers a Telephone Number Mapping (ENUM) service for 
Internet Calendaring Services.  Specifically, this document focuses  on
provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM.

Working Group Summary

The document is one of a number of enumservice registrations in the
series. The application suggests a mapping of phone number to find a
calendaring service.

Protocol Quality

This document was reviewed for the IESG by Jon Peterson. Richard Shockey
is the PROTO Shepherd. GEN-ART review was provided by David Black.

I-D Action: New draft - draft-bellis-enum-send-n-00

I've just submitted a new I-D, available at
<http://www.ietf.org/internet-drafts/draft-bellis-enum-send-n-00.txt>

Filename:        draft-bellis-enum-send-n
Revision:        00
Title:           IANA Registrations for the 'Send-N' Enumservice
Creation_date:   2008-04-02
WG ID:           Independent Submission
Number_of_pages: 10

Abstract:

  This document requests IANA registration of an Enumservice 'Send-N'
  and extends the definition of the 'pstndata:' URI scheme.  This
  service allows more efficient support for overlapped dialling in
  E.164 Number Mapping (ENUM) enabled applications.

Any and all (constructive) feedback gratefully received!

regards,

Ray

--

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: ray <at> nominet.org.uk, t: +44 1865 332211

Re: I-D Action: New draft - draft-bellis-enum-send-n-00

Ray:
I'm having a little trouble understanding the real need for this
enumservice. I would think that any network element  receiving a dial
string would have its own local information about dial patterns and
numbers and so be able to tell when dialing is complete and then be able
to formulate an ENUM query on the appropriate full E.164 number.
Since the number length information should be relatively static, why not
just provision it locally? 
Also, it's not clear to me when the client would initiate the initial
query in the example that told it to expect 5-6 more digits. And, if
it's 5-6, then if the number has only 5, don't I still have to use a
timeout algorithm to determine the user is finished dialing.
Am I missing something?

Penn Pfautz

-----Original Message-----
From: enum-bounces <at> ietf.org [mailto:enum-bounces <at> ietf.org] On Behalf Of
Ray.Bellis <at> nominet.org.uk
Sent: Wednesday, April 02, 2008 4:40 AM
To: enum <at> ietf.org
Subject: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

I've just submitted a new I-D, available at
<http://www.ietf.org/internet-drafts/draft-bellis-enum-send-n-00.txt>

Filename:        draft-bellis-enum-send-n
Revision:        00
Title:           IANA Registrations for the 'Send-N' Enumservice
Creation_date:   2008-04-02

Re: I-D Action: New draft - draft-bellis-enum-send-n-00

PFAUTZ, PENN L, ATTCORP said:
> I'm having a little trouble understanding the real need for this
> enumservice. I would think that any network element  receiving a dial
> string would have its own local information about dial patterns and
> numbers and so be able to tell when dialing is complete and then be able
> to formulate an ENUM query on the appropriate full E.164 number.
> Since the number length information should be relatively static, why not
> just provision it locally? 

While the information should be static, it's also very complicated and it
might not be practical for the network element to store it all. In the UK
we have number ranges where the length varies in a very localised way; it
might be that:
     0456 789 0xx    numbers are all 10 digits
     0456 789 1xxx   numbers are all 11 digits
(these are hypothetical examples because I can't get to the relevant
database right now).

Germany has situations where the customer determines the length of numbers.

> Also, it's not clear to me when the client would initiate the initial
> query in the example that told it to expect 5-6 more digits.

The client would know, perhaps, that *every* number beginning 0 has at
least 7 digits. So it would initiate the query after receiving those 7.

> And, if
> it's 5-6, then if the number has only 5, don't I still have to use a
> timeout algorithm to determine the user is finished dialing.
> Am I missing something?

Re: I-D Action: New draft - draft-bellis-enum-send-n-00

Clive D.W. Feather wrote:

> While the information should be static, it's also very complicated and it
> might not be practical for the network element to store it all. In the UK
> we have number ranges where the length varies in a very localised way; it
> might be that:

A similar thing occurs in Australia and I recently parsed the CSV file
published by the ACMA of all prefixes it is authorised to allocate or
has been allocated and its a horrible mess of sorts. So I can see how
this might be useful especially for keeping up with changes globally to
the benefit of all but without everyone needing to keep local databases
or updating their own databases themselves.

> The client would know, perhaps, that *every* number beginning 0 has at
> least 7 digits. So it would initiate the query after receiving those 7.

I'm not exactly clear on when DNS queries should be triggered, or how
many need to be requested either or if these would interfere with
existing wild card entries.

I don't have time this morning to test but I like the idea a lot and I
very much would like to see it or some variation of it work.

--

-- 

Best regards,
 Duane

Re: I-D Action: New draft - draft-bellis-enum-send-n-00

Duane wrote:
> Clive D.W. Feather wrote:
> 
>> While the information should be static, it's also very complicated and it
>> might not be practical for the network element to store it all. In the UK
>> we have number ranges where the length varies in a very localised way; it
>> might be that:
> 
> A similar thing occurs in Australia and I recently parsed the CSV file
> published by the ACMA of all prefixes it is authorised to allocate or
> has been allocated and its a horrible mess of sorts. So I can see how
> this might be useful especially for keeping up with changes globally to
> the benefit of all but without everyone needing to keep local databases
> or updating their own databases themselves.

I meant to provide a link to the results of where I parsed the
Australian information in the first place, sorry.

http://www.e164.org/wiki/AU_Dialplan

The information at the top is a simplified version which most people
would be able to live with, however the full listing which appears at
the bottom is the most accurate description of the Australian numbering
plan as of about 3 weeks ago.

--

-- 

Best regards,
 Duane

Re: I-D Action: New draft - draft-bellis-enum-send-n-00

This would be good *if* we could be assured that there would be enough 
public ENUM entries to define the endpoint of all dial strings.

I guess each device must at least know how to get to the country level. 
After that, there ought to at least be one of these entries for the 
country code. For each country there ought to be either a fixed length 
or a range. If a range, then there ought to be an entry for each string 
of length equal to the minimum of the range, which narrows it down.

Then the USA could continue to dawdle on enum support, since there can 
be a fixed length for all of the NANP. Those countries with variable 
length numbers would have a harder requirement for enum support.

	Paul

Duane wrote:
> Clive D.W. Feather wrote:
> 
>> While the information should be static, it's also very complicated and it
>> might not be practical for the network element to store it all. In the UK
>> we have number ranges where the length varies in a very localised way; it
>> might be that:
> 
> A similar thing occurs in Australia and I recently parsed the CSV file
> published by the ACMA of all prefixes it is authorised to allocate or
> has been allocated and its a horrible mess of sorts. So I can see how
> this might be useful especially for keeping up with changes globally to
> the benefit of all but without everyone needing to keep local databases
> or updating their own databases themselves.
> 

Re: I-D Action: New draft - draft-bellis-enum-send-n-00

Hi Clive, Penn, Ray, folks,

I am somewhat discomforted by this thread. IMHO it's a damn good idea  
having (in effect) an digit length analysis tree in DNS. It sure as  
heck beats looking through the different CSV/Excel/Access/... formats  
in which different Regulators publish their number plans.

However, the ENUM standard doesn't seem to be set up to allow  
definition of these useful records. This may not be appropriate for  
E2U, but instead be another DDDS application entirely. Otmar, Alex,  
and Michael have had similar ideas, and they didn't prevail even  
though they were neat proposals. Heck, Rchard Stastny and I had some  
fun with VOID, and were reminded that THAT won't fly in ENUM with  
block numbers.

Scott has released a draft of rfc3761bis-03.
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.

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 :).

In principle only having a partial view of global number plans is not  
good enough. The idea of provisioning every nation state's number plan  
locally into every switch is surely not what was meant. **

Re: I-D Action: New draft - draft-bellis-enum-send-n-00

Chair hat off ..

Lawrence I generally agree with the thrust of your analysis. I find it very
difficult to support the use of 3761 for digit analysis. 3761 was designed
to query on the full E.164 string not a partial string. We would be going
down a rat hole we do not want to go, especially now.

ENUM is a pure 1 to 1 mapping from fully formed E.164 FQDN to URI's. The
digit strings must be fully formed in advance before query not during. We
have seen the German arguments etc and have passed on those etc.

>  -----Original Message-----
>  From: enum-bounces <at> ietf.org [mailto:enum-bounces <at> ietf.org] On Behalf
>  Of Lawrence Conroy
>  Sent: Wednesday, April 02, 2008 7:31 PM
>  To: Clive D.W.Feather
>  Cc: Ray.Bellis <at> nominet.org.uk; enum <at> ietf.org; PFAUTZ, PENN L, ATTCORP
>  Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-
>  00
>  
>  Hi Clive, Penn, Ray, folks,
>  
>  I am somewhat discomforted by this thread. IMHO it's a damn good idea
>  having (in effect) an digit length analysis tree in DNS. It sure as
>  heck beats looking through the different CSV/Excel/Access/... formats
>  in which different Regulators publish their number plans.
>  
>  However, the ENUM standard doesn't seem to be set up to allow
>  definition of these useful records. This may not be appropriate for
>  E2U, but instead be another DDDS application entirely. Otmar, Alex,