Subject: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt

From: [email-masked]
Date: Fri, 21 Oct 2005 10:50:01 -0400

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		: IANA Registration for Enumservice VOID
	Author(s)	: R. Stastny, et al.
	Filename	: draft-ietf-enum-void-02.txt
	Pages		: 19
	Date		: 2005-10-21
	
This document registers the Enumservice 'void' using the URI schemes
   'mailto:' and 'http:' as per the IANA registration process defined in
   the ENUM specification, RFC3761.  This Enumservice may be used to
   indicate that the E.164 number (or E.164 number range) tied to the
   domain in which the enclosing NAPTR is published is not assigned for
   communications service.  When such an indication is provided, an ENUM
   client can detect calls that will fail "early".

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-enum-void-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-enum-void-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 24 Oct 2005 11:48:51 -0400

> 	Filename	: draft-ietf-enum-void-02.txt

I know this draft has been around for awhile so excuse me if I
inadvertently bring up a question that may have been discussed
previously.  Is there any reason the draft could not also include
subtypes for SIP and tel URIs?

Regards
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 25 Oct 2005 17:06:25 -0400

> I can remember we considered this, but left it to e-mail and 
> web, and I personally consider even e-mail problematic, 
> because There will be at least one client designer out there 
> having had not enough coffee in the morning and program a 
> client directly sending an e-mail during call set-up
> 
> IMHO the best solution for an NRA is to point to a web-page 
> where the NRA may list e-mail addresses or phone numbers for 
> contact id something is wrong with the entry

Thank you for the reply.  

If I understand how the I-D would be used in practice - when a switch or
client sees a VOID record, that will probably trigger it to play an
announcement to tell the user the number is inactive ("dee-doo-dee.
This number is not currently in service.  Please check your number and
dial again.").  I suspect some clients may choose to discard / ignore
the extra contact info provided, such as the http address, and just play
this locally-stored announcement.  

But thinking beyond the traditional phone instrument to soft phones and
how announcements are viewed today, there may be more possibilities (I
am no expert here, btw).  Perhaps a tel URI could be used for the
display the telephone number of the service provider's customer service
line (similar to the URL for the customer service department) if it
appears in the VOID record.  Or perhaps some service providers will want
a SIP URI to achieve the same end, or even to route the caller to a
specialized announcement instead of the one that is stored by the
switch/client (sip:[email-masked], IVR system on the line
picks up and plays "This XYZ VoIP number is not currently in service.
If you believe you have received this message in error, press 1 now.  To
sign up for service now, press 2."  etc, etc.).  Or maybe the SP didn't
even buy a traditional announcement server and the URI goes to some
generic, to-be-created service like
sip:[email-masked].  ??

Of course, clients may choose to ignore this information as well.  But
at least the info would be present as an option in the future so we
needn't come back to revise VOID.  I could also see SPs trying to do the
example above anyway, by not using VOIDs at all and simply populating a
generic not-in-service SIP URI using E2U+SIP.  I do not feel that is the
desired result or necessarily advisable from an architecture
perspective.  But I'd rather give them the alternative of indicating the
number as VOID and additionally giving a client the option of acting on
a SIP or tel URI.

Anyway, something to mull over a bit perhaps...

Regards,
Jason

> Richard
> 
> > -----Original Message-----
> > From: Livingood, Jason [mailto:[email-masked]]
> > Sent: Monday, October 24, 2005 5:49 PM
> > To: [email-masked]; Stastny Richard; [email-masked]; [email-masked]
> > Subject: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt
> > 
> >

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 25 Oct 2005 23:46:02 +0200

Jason,
 
I think there is a misunderstanding here on the basic purpose
of the VOID Enumservice, basically regarding the responsibility
for the domain containing this NAPTR
 
You assumption is that a number range is assigned to a 
VoIP provider and the VOIP has not yet assigned the number
to the end-user. The assumption here is that the VoIP provider
is already responsible for the number in question.

This may be the case, and it is up to the VOIP provider
if he simple enters a VOID NAPTR triggering the default
dee-do-dee you mention
OR providing an special announcement, but then eg
with a normal SIP URI pointing somewhere (eg
your examples)
 
But there is also an other approach possible, eg with
our number range 0780 for ENUM. Numbers are assigend
here 1 by one to end-users and the end-user in turn assignes
the number to a VoIP service provider by pointing the
URI to the VoIP SP.

A similar case may happen fcarrier ENUM or 800 numbers 
or corporate numbers assigned
1 by 1 first to the customer and then by the customer
to the VoIP provider.

In this cases an assigned number is NOT assigned to any 
VoIP provider yet, it is really unassigend and still belongs
to the pool of the regulator. So the basic idea was to point here
to the webpage of the regulator only in the RARE case somebody
believes that something is wrong here.

The void enumservice is also intended to be used for yet unassigned
area codes eg 1-747 in the US.Also this range still "belongs" to the
NANP admin.

I hope this clarifies the isuue somewhat.

regards

Richard

________________________________

Von: Livingood, Jason [mailto:[email-masked]]
Gesendet: Di 25.10.2005 23:06
An: Stastny Richard; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt 

Thank you for the reply. 

Regards,
Jason

---

From: "Conroy, Lawrence \(SMTP\)" <[email-masked]>
Date: Tue, 25 Oct 2005 14:53:49 +0100

Hi Ray, folks,
   Forgive, but why on a phone?
This is NOT during call setup.
Only offline, if there's a problem (e.g. your assignment is marked as  
VOID).

all the best,
   Lawrence

On 25 Oct 2005, at 14:41, Ray Anderson wrote:
> And make sure that the web page works on the more popular devices  
> like phones, as well as on PC's
> (i.e. support WML, XHTML etc.)
> Ray
> At 12:41 25/10/2005, Stastny Richard wrote:
>
>> Jason,
>>
>> I can remember we considered this, but left it to e-mail and web,
>> and I personally consider even e-mail problematic, because
>> There will be at least one client designer out there having
>> had not enough coffee in the morning and program a client
>> directly sending an e-mail during call set-up
>>

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 26 Oct 2005 10:01:55 -0400

Okay, I better understand your use case now.  

So to summarize, there is an entity that holds a block of numbers.  Let
us say 1,000 numbers for example.  This entity in the case of Austria
could be the enum.at registry or other entity that hands 0780 numbers
out to users directly, on an individual basis (please excuse my lack of
understanding of who hands out the special 0780 numbers).  In the US, it
could be a SP that has been delegated a block of 1,000 numbers by the
NRA that are, in turn, handed out to subscribers.  Or perhaps it is a
university campus that has a big IP-PBX with 1,000 numbers and activates
the numbers when students come to school each year. 

In all of these cases, using the 1,000 number example, 900 of the
numbers are not yet activated and 100 are active with E2U+SIP NAPTRs.
The other 900 have VOID records.  In the case of Austria and the 0780
range, you may want E2U+void:http, to give the homepage of enum.at or
whatever, in case someone wishes to report an error or figure out why it
is not active.  

So I suppose what I am asking is, do you think that the http, https, and
mailto subtypes of VOID solve all potential and future use cases of VOID
that one could imagine?  To that end, is it worth considering the
addition of tel and SIP subtypes to VOID (based on a few quick
possibilities outlined in my earlier email)?  As I said, if we think
they may be useful by someone in the future, perhaps it is better to
consider them now than have to revise the draft in 2 years to make some
additions.

Regards,
Jason

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Tuesday, October 25, 2005 5:46 PM
> To: Livingood, Jason; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-void-02.txt 
> 
> Jason,
>  
> of the VOID Enumservice, basically regarding the 
> responsibility for the domain containing this NAPTR
>  
> You assumption is that a number range is assigned to a VoIP 
> provider and the VOIP has not yet assigned the number to the 
> end-user. The assumption here is that the VoIP provider is 
> already responsible for the number in question.
> 
> This may be the case, and it is up to the VOIP provider if he 
> simple enters a VOID NAPTR triggering the default dee-do-dee 
> you mention OR providing an special announcement, but then eg 
> with a normal SIP URI pointing somewhere (eg your examples)
>  
> But there is also an other approach possible, eg with our 
> number range 0780 for ENUM. Numbers are assigend here 1 by 
> one to end-users and the end-user in turn assignes the number 
> to a VoIP service provider by pointing the URI to the VoIP SP.
> 
> A similar case may happen fcarrier ENUM or 800 numbers or 
> corporate numbers assigned
> 1 by 1 first to the customer and then by the customer to the 
> VoIP provider.
> 
> In this cases an assigned number is NOT assigned to any VoIP 
> provider yet, it is really unassigend and still belongs to 
> the pool of the regulator. So the basic idea was to point 
> here to the webpage of the regulator only in the RARE case 
> somebody believes that something is wrong here.
> 
> The void enumservice is also intended to be used for yet 
> unassigned area codes eg 1-747 in the US.Also this range 
> still "belongs" to the NANP admin.
> 
> > I can remember we considered this, but left it to e-mail 
> and web, and 
> > I personally consider even e-mail problematic, because 
> There will be 
> > at least one client designer out there having had not 
> enough coffee in 
> > the morning and program a client directly sending an e-mail during 
> > call set-up
> >
> where the 
> > NRA may list e-mail addresses or phone numbers for contact id 
> > something is wrong with the entry
> 
> Thank you for the reply. 
> 
> If I understand how the I-D would be used in practice - when 
> a switch or client sees a VOID record, that will probably 
> trigger it to play an announcement to tell the user the 
> number is inactive ("dee-doo-dee.
> This number is not currently in service.  Please check your 
> number and dial again.").  I suspect some clients may choose 
> to discard / ignore the extra contact info provided, such as 
> the http address, and just play this locally-stored announcement. 
> 
> But thinking beyond the traditional phone instrument to soft 
> phones and how announcements are viewed today, there may be 
> more possibilities (I am no expert here, btw).  Perhaps a tel 
> URI could be used for the display the telephone number of the 
> service provider's customer service line (similar to the URL 
> for the customer service department) if it appears in the 
> VOID record.  Or perhaps some service providers will want a 
> SIP URI to achieve the same end, or even to route the caller 
> to a specialized announcement instead of the one that is 
> stored by the switch/client 
> (sip:[email-masked], IVR system on the line 
> If you believe you have received this message in error, press 
> 1 now.  To sign up for service now, press 2."  etc, etc.).  
> Or maybe the SP didn't even buy a traditional announcement 
> server and the URI goes to some generic, to-be-created 
> service like sip:[email-masked].  ??
> 
> Of course, clients may choose to ignore this information as 
> well.  But at least the info would be present as an option in 
> the future so we needn't come back to revise VOID.  I could 
> also see SPs trying to do the example above anyway, by not 
> using VOIDs at all and simply populating a generic 
> not-in-service SIP URI using E2U+SIP.  I do not feel that is 
> the desired result or necessarily advisable from an 
> architecture perspective.  But I'd rather give them the 
> alternative of indicating the number as VOID and additionally 
> giving a client the option of acting on a SIP or tel URI.
>