Subject: Re: [Enum] draft-ietf-enum-unused-00.txt

From: "Lupton, Ronan" <[email-masked]>
Date: Wed, 17 Jan 2007 10:17:39 -0000

Richard,

Just so we don't confuse people, DDI in ENUM speak is different to DDI PSTN
speak. What we mean in the ENUM context is digits over and above the
expected national lengths, whereas in PSTN speak we or many understand it to
conform or be part of a ISDN standard set up or config.

No, we couldn't have any changes not after debating it for so long at this
stage. 

Austria are after all leading the charge!!

Ronan 

-----Original Message-----
From: Stastny Richard <[email-masked]>
To: Lupton, Ronan; [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
CC: [email-masked] <[email-masked]>
Sent: Wed Jan 17 10:08:16 2007
Subject: RE: [Enum] draft-ietf-enum-unused-00.txt

Ronan,

>DDI being suffix to national numbering schema expected rather than the
old >telco PABX DDI as many know it! 

I do not really understand what you want to say

>There is no escape from this in Austria, Germany and perhaps one other
>country. 

Do you mean Austria has to change this?

No plans yet

Richard

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 17 Jan 2007 11:26:40 +0100

Ronan,

>Just so we don't confuse people, DDI in ENUM speak is different to DDI
PSTN >speak. What we mean in the ENUM context is digits over and above
the >expected national lengths, whereas in PSTN speak we or many
understand it >to conform or be part of an ISDN standard set up or
config.

This is not correct:
1. There is no "expected" national length in open numbering plans

2. Please look at E.164-Annex B

"In instances where a partial number is utilized, the number will be
used in the context of direct-dialling-in supplementary service."

This has nothing to do with ISDN Subaddress

SA is something else and comes after the partial number:

B.3.4 "Sub-addressing may be used separately or in combination with the 
partial number"

Richard

>No, we couldn't have any changes not after debating it for so long at
this >stage. 

-----Original Message----- 
From: Stastny Richard <[email-masked]> 
To: Lupton, Ronan; [email-masked] <[email-masked]>;

Ronan,

---

From: [email-masked]
Date: Wed, 17 Jan 2007 09:27:29 -0500

From: "Stastny Richard" <[email-masked]>

Is there a way to use a subaddress with a number that is translated
through ENUM?

Dale

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 17 Jan 2007 15:48:32 +0100

> Is there a way to use a subaddress with a number that is translated
This is a good question:

First: ENUM is only to be used for E.164 numbers. Since the SA is
not part of an E.164 number, it cannot be used by the originator
to be queried in ENUM.

It has to be signalled separately

This raises the question how to detect the SA part in a dialstring

I have no idea

Additional note: as far as I know there exist some parameters
to the tel: URI so signal isdn SA.

But this does not help ENUM

Richard

---

From: [email-masked]
Date: Wed, 17 Jan 2007 17:29:14 -0500

In RFC 3966:

5.2.  ISDN Subaddresses

   A phone number MAY also contain an 'isdn-subaddress' parameter that
   indicates an ISDN subaddress.
   ISDN subaddresses typically contain International Alphabet 5 (IA5
   [T.50]) characters but may contain any octet value.

Note that the BNF variable for this parameter is "isdn-subaddress",
but the parameter name itself is "isub".

It would be sensible if the ENUM resolution process attached the isub
parameter from the tel URI onto the SIP URI obtained from resolution,
but I don't think there is any specification for that.

Dale

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 17 Jan 2007 23:43:05 +0100

>but I don't think there is any specification for that.

This is not the problem - a tel: or sip: URI in an ENUM NAPTR
may always contain the isdn-subaddress

The problem is that you cannot query an E.164 number + SA
in ENUM and e.g. get different results for each SA
 
Richard

________________________________

Von: [email-masked] [mailto:[email-masked]]
Gesendet: Mi 17.01.2007 23:29
An: [email-masked]
Betreff: Re: [Enum] draft-ietf-enum-unused-00.txt

In RFC 3966:

5.2.  ISDN Subaddresses

Dale

---

From: [email-masked]
Date: Thu, 18 Jan 2007 10:06:26 -0500

Yes, but if I write "tel:12125551212;isub=1234" the isub information
is lost when it is resolved into a SIP URI.  Or at least, as far as I
can figure out from a quick scan of RFC 3761 and 3764.  Ideally, the
ENUM resolution process would specify that the isub parameter would be
carried from the tel: URI to the sip: URI.

   The problem is that you cannot query an E.164 number + SA in ENUM
   and e.g. get different results for each SA

True, though presently I don't see that as a major problem, because
the E.164 number has to be allocated to one customer, who can then run
a proxy that will forward requests based on SA to various
destinations.

Hmmmm, in some models of User-ENUM, a user could install ENUM records
not for his E.164 number, but for longer numbers with that E.164
number as prefix, and achieve an effect much like what you want.

Dale

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 18 Jan 2007 16:49:21 +0100

> is lost when it is resolved into a SIP URI.

No, you can carry all tel parameters to the sip URI
sip:+12125551212;isub=[email-masked]

> number as prefix, and achieve an effect much like what you want.

I do not think that this is possible

Richard

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 18, 2007 4:06 PM
> To: [email-masked]
> Subject: Re: [Enum] draft-ietf-enum-unused-00.txt
>

---

From: [email-masked]
Date: Thu, 18 Jan 2007 16:22:46 -0500

But I don't see any prescription anywhere that you *should*, and
without that, many resolvers *won't*.

It depends on how your DNS is managed.  But it would be a hack and not
be assured of interoperability.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jan 2007 16:58:48 -0500

> without that, many resolvers *won't*.

So is Richard suggesting that if the enum mapping is:
    tel:12125551212 => sip:[email-masked]

then the following should also occur:
    tel:12125551212;isub=1234 => sip:+12125551212;isub=[email-masked]

???

I am certainly not aware of how you would get that to happen.
Even if you could, what if the enum mapping is:

    tel:12125551212 => sip:[email-masked]

Do you then want the following mapping to also occur:

    tel:12125551212;isub=1234 => sip:john.doe;isub=[email-masked]

That seems rather inappropriate to me.

	Paul

---

From: [email-masked]
Date: Thu, 18 Jan 2007 20:40:29 -0500

From: Paul Kyzivat <[email-masked]>

I'm thinking that this would be a good idea:

tel:12125551212;isub=1234 => sip:[email-masked];isub=1234

But consider:

tel:12125551212;isub=1234 => sip:[email-masked];isub=1234

If UAs ignore URI-parameters that they don't understand, it's
upward-compatible.

Dale

---

From: lconroy <[email-masked]>
Date: Fri, 19 Jan 2007 13:06:16 +0000

Hi Dale, Richard, folks,
  This thread reflects earlier discussion on the IPTEL list when 3966
was being developed (and other threads covering mapping of tel: paras
into sip: URIs). Search for tel: paramaters vs. uri: parameters.

However, we do need to be careful about what is meant by mapping.

It looks like Dale is talking about provisioning sub-domains into ENUM
space to cover digit strings of which the end parts are sub-addresses.

However... A client may know that a sub-address is not part of an E.164
number. It surely will know this if it gets a tel: URI with an ;isub
parameter. The main value is the E.164 number. The ;isub is discrete.

Section 2 of RFC 3761 is specific:
  "ENUM compliant applications MUST only query DNS for what it believes
   is an E.164 number."

My interpretation is that this bars creating separate sub-domains for
such concatenated numbers, as they are not E.164 numbers.

all the best,
   Lawrence

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 19 Jan 2007 14:12:11 +0100

> such concatenated numbers, as they are not E.164 numbers.

That is what I said

And BTW, I would like to move this discussion somewhere else
because it is completely off-topic re "unused"

I would also like to move the discussions about 11D NANPA
numbers of this thread

Richard

> From: lconroy [mailto:[email-masked]]
> Sent: Friday, January 19, 2007 2:06 PM
> To: [email-masked]
> Cc: IETF ENUM WG; Stastny Richard