Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 24 Sep 2012 22:10:19 +0200

Hi,

as an author of draft-ietf-mmusic-sdp-cs

The authors were addressing the comments that we got back in February 
from Flemming. His complete e-mail was this one:

http://www.ietf.org/mail-archive/web/mmusic/current/msg09367.html

The authors have addressed all the comments, except the first one. We 
require a bit more of discussion on the list. I reproduce here the comment:

1) The document defines the "E164" 'addrtype' type as well as the "-" 
'addrtype' to be used in the "c=" line and wants to register these with 
IANA. As it turns out, RFC 3108 also defined these, however they never 
got registered with IANA. While the '-' seems to be defined similarly, 
the syntax for the "164" differs between the two, which is obviously a 
problem, not least considering RFC 3108 is Standards Track. Also, for 
some reason the cs-draft lists RFC 3108 as a normative reference, but it 
does not provide any normative text for its use.

The problem that is not listed here is the definition fo the "E164" 
'addrtype' in RFC 3108. I include here the relevant text:

    E164: If the addressType is E164, the address is expressed as a
    decimal number  with up to 15 digits.  For example:

         c=ATM E164 9738294382

    The use of E.164 numbers in the B-ISDN context is defined in ITU
    E.191.  There is a disparity between the ATM forum and the ITU in the
    use of E.164 numbers for ATM addressing.  The ATM forum (e.g., UNI
    Signaling 4.0) allows only International Format E.164 numbers, while
    the ITU (e.g., Q.2931) allows private numbering plans.  Since the
    goal of this SDP specification is to interoperate with all bearer
    signaling protocols, it allows the use of numbers that do not conform
    to the E.164 International Format.  However, to maximize overall
    consistency, network administrators can restrict the provisioning of
    numbers to the E.164 International Format.

The SDP CS draft indicates that only international E164 number must be 
used, and adds a '+' sign to indicate the international format of the 
number. RFC 3108 seems to allow both international and national format, 
but does not add the '+' sign to indicate that a digit-string means 
international format.

At first glance, one solution could be that the CS draft will use another 
addrtype, for example, "INTE164", to indicate international E.164 
numbers. However, being the CS draft a dependency to 3GPP Release 8 
(which was technical frozen in 2009), I think it is not fair to do this 
last-minute change at this stage. And I will be worried if there are 
already implementations deployed.

I want to stress that the usages of ATM in SDP and CS in SDP do not 
clash. I mean, the usage is so different that it is hard to foresee an 
implementation that will use RFC 3108 and SDP CS *at the same time*.

So, let me have a proposal that I believe will satisfy both RFC 3108 and 
the SDP CS draft.

The idea is to keep on using the "E164" addrtype in both documents. SDP 
CS needs to define the E164 number indicating that can convey both 
international and national numbers. If an international number is used, 
it is prepended by a '+' sign (as the draft currently says). If a '+' is 
written, then it is an international format. If a '+' sign is absent then 
it is up to the implementation to determine the scope of the number 
(national or international). The lack of '+' sign will only occur in the 
context of RFC 3108.

SDP CS will keep on only using international E.164 numbers, represented 
with the '+' sign, and will register (as it currently does) the "E164" 
'addrtype' with IANA.

Is this acceptable?

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Sep 2012 17:11:09 -0400

>     numbers to the E.164 International Format.

This is the first time I have looked at 3108. Based on a quick look, it 
seems very broken in this regard, and seems a bad model to emulate.

The example it gives (c=ATM E164 9738294382) is apparently not an E.164 
number. (If it is, then the country code is 97, which is Bahrain, and 
the remainder of the number doesn't seem consistent with that.) It 
*appears* to be a US number in New Jersey, without the country code.
(Everybody who reads this should give it a call!)

If we consider that the example is in error and should have used 
19738294382, then it is still ambiguous whether any given number is in 
E.164 format or is from a private numbering plan. I took a peek at 
Q.2931 and it passes an address type that distinguishes these, but 
"C=ATM E164" has no way to do so. It is just broken.

> At first glance, one solution could be that the CS draft will use
> another addrtype, for example, "INTE164", to indicate international
> E.164 numbers. However, being the CS draft a dependency to 3GPP Release
> 8 (which was technical frozen in 2009), I think it is not fair to do
> this last-minute change at this stage. And I will be worried if there
> are already implementations deployed.
>
> written, then it is an international format.

Seems right.

> If a '+' sign is absent
> then it is up to the implementation to determine the scope of the number

ISTM that this is still ambiguous. Q.2931 defines
- unknown
- international number
- national number
- network specific number
- subscriber number
- abbreviated number

My counter suggestion would be to use tel format - 
'telephone-subscriber' syntax as defined in RFC3966. At least that has a 
real definition. It doesn't cover all the options Q.2931 does, but it 
covers global (E.164) and local, and a number of qualifiers for local.

> with the '+' sign, and will register (as it currently does) the "E164"

It is fine with me that SDP CS will keep using "+".

	Thanks,
	Paul

---

From: Andrew Allen <[email-masked]>
Date: Mon, 24 Sep 2012 23:47:33 +0000

I agree. 

Let's not change the format in CS draft as this has been frozen in 3GPP for several years and may have already been implemented.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Miguel A. Garcia
> Sent: Monday, September 24, 2012 3:10 PM
> To: mmusic
> Cc: Flemming Andreasen
> Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft
> 
> Hi,
> 
> another
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Atle Monrad <[email-masked]>
Date: Tue, 25 Sep 2012 10:47:12 +0200

Miguel

3GPP has referred to this draft since Rel-8. Avoidance of last-minute changes to the coding would be appreciated.

Your proposed way forward seems good to me.

Thanks
/atle

________________________________ 

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel A. Garcia
Sent: 24. september 2012 22:10
To: mmusic
Cc: Flemming Andreasen
Subject: [MMUSIC] Issue with E164 numbers in SDP CS draft

Hi,

The authors were addressing the comments that we got back in February from Flemming. His complete e-mail was this one:

The authors have addressed all the comments, except the first one. We require a bit more of discussion on the list. I reproduce here the comment:

1) The document defines the "E164" 'addrtype' type as well as the "-" 
'addrtype' to be used in the "c=" line and wants to register these with IANA. As it turns out, RFC 3108 also defined these, however they never got registered with IANA. While the '-' seems to be defined similarly, the syntax for the "164" differs between the two, which is obviously a problem, not least considering RFC 3108 is Standards Track. Also, for some reason the cs-draft lists RFC 3108 as a normative reference, but it does not provide any normative text for its use.

         c=ATM E164 9738294382

The SDP CS draft indicates that only international E164 number must be used, and adds a '+' sign to indicate the international format of the number. RFC 3108 seems to allow both international and national format, but does not add the '+' sign to indicate that a digit-string means international format.

At first glance, one solution could be that the CS draft will use another addrtype, for example, "INTE164", to indicate international E.164 numbers. However, being the CS draft a dependency to 3GPP Release 8 (which was technical frozen in 2009), I think it is not fair to do this last-minute change at this stage. And I will be worried if there are already implementations deployed.

I want to stress that the usages of ATM in SDP and CS in SDP do not clash. I mean, the usage is so different that it is hard to foresee an implementation that will use RFC 3108 and SDP CS *at the same time*.

So, let me have a proposal that I believe will satisfy both RFC 3108 and the SDP CS draft.

The idea is to keep on using the "E164" addrtype in both documents. SDP CS needs to define the E164 number indicating that can convey both international and national numbers. If an international number is used, it is prepended by a '+' sign (as the draft currently says). If a '+' is written, then it is an international format. If a '+' sign is absent then it is up to the implementation to determine the scope of the number (national or international). The lack of '+' sign will only occur in the context of RFC 3108.

SDP CS will keep on only using international E.164 numbers, represented with the '+' sign, and will register (as it currently does) the "E164" 
'addrtype' with IANA.

Is this acceptable?

/Miguel

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 25 Sep 2012 12:51:35 -0400

So it seems we have a way forward here that will work for everybody and 
allow us to come up with a single E164 IANA registration for both RFC 
3108 and SDP-CS, but please note that all Internet Drafts include the 
following text for a reason:

<quote>

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
</qutoe>

If people do plan on making use of and/or reference to an 
Internet-Draft, please let the WG and authors know so we can give 
adequate priority to the work and hence provide a stable reference in 
the form of an RFC (as has already been done by 3GPP for a couple of 
other drafts)

Thanks

-- Flemming  (as MMUSIC co-chair)

On 9/25/12 4:47 AM, Atle Monrad wrote:
> .

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Sep 2012 13:15:18 -0400

On 9/25/12 12:51 PM, Flemming Andreasen wrote:
> 3108 and SDP-CS,

What is the single way that works for both?
I don't see that without an update to 3108.

RFC 3108 doesn't support the '+' and purports to support both global and 
local without it. But you can't really support both global and local 
numbers without *some* non-numeric characters. (Unless you go with dial 
strings, which are themselves not global.)

	Thanks,
	Paul

> but please note that all Internet Drafts include the

>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Miguel A. Garcia

---

From: Miguel Garcia A <[email-masked]>
Date: Tue, 25 Sep 2012 20:19:06 +0200

Paul:

The problem, IMHO, lies in RFC 3108, because it allows both national and international numbering plans without separating the context. 

With or without the CS draft, RFC 3108 seems to have a problem. In spite of other problems (the draft fails to register E164 and perhaps some other parameters.

As I said before, there is not foresee usage of the E164 number scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on using the mechanism they are currently using. The SDP CS draft will register the E164 with IANA with the syntax that may optionally include a plus sign. This does not affect current implementations of RFC 3108.

BR,

     Miguel
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Tuesday, September 25, 2012 7:15 PM
To: [email-masked]
Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Sep 2012 16:45:36 -0400

> As I said before, there is not foresee usage of the E164 number scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on using the mechanism they are currently using. The SDP CS draft w…

I agree the problem is with 3108.
And I have no problem with the SDP CS draft registering E164 with 
numbers starting with '+'.

But I do have a little trouble with this draft registering E164 in a way 
that permits numbers without the '+'. The problem with doing this is 
defining what it means - how to interpret the number in that case. Just 
saying it means "local" without defining what "local" means is not a 
good thing.

So, I see two ways forward:

- only define values consisting of '+' and digits.
   Leave anything more to be done later if anyone
   cares.

- do a complete definition of both global and local
   numbers. In that case I would suggest referring to
   'telephone-subscriber' from RFC3966 rather than
   trying to start from scratch.

Either of these work for me, though I would slightly prefer referencing 
RFC3966, because it gives a more robust definition.

	Thanks,
	Paul

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 25 Sep 2012 22:27:09 +0100

Hi Folks,
 Me too. Personally, I would STRONGLY prefer that folks pulled the definition from 3966 (whichever of the two choices you make).

We had similar mantras to chant in ENUM, so I feel for the squirming here.

See the last para of RFC4415 section 3 for the appropriate syntax references to RFC3966 -- yes, you DO need to refer to that, and I'd suggest normatively.
National/Local numbers are not necessarily the same as dial strings (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be a number rather than any old dial string (with or without the preceding '9', with or without a carrier prefix, with or without a trunk "access" digit, ...).
That's why we strongly discouraged anything other than global numbers -- otherwise you're building in yet another "NAT" problem.

See the text in the 2nd para of the intro to RFC6116 for the "anointed" spec/definition we used for "E.164 number".
BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIRC, the '+' comes from 3GPP and from TIA specs.
Also, you may want to specify that the "punctuation" that E.164 permits is excluded (assuming you don't want dashes, commas, dots or spaces in the middle).

all the best,
 Lawrence

On 25 Sep 2012, at 21:45, Paul Kyzivat wrote:
> And I have no problem with the SDP CS draft registering E164 with numbers starting with '+'.
> 
> But I do have a little trouble with this draft registering E164 in a way that permits numbers without the '+'. The problem with doing this is defining what it means - how to interpret the number in that case. Just saying it means "local" without defining what "local" means is not a good thing.
> 
> Either of these work for me, though I would slightly prefer referencing RFC3966, because it gives a more robust definition.
> 
> 	Thanks,
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Sep 2012 17:50:27 -0400

> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIRC, the '+' comes from 3GPP and from TIA specs.

RFC3108 *could* be valid without the '+' if it only permitted E.164 
(global) numbers. But it claims to support both International Format 
E.164 numbers and private numbering plans. For that it is invalid 
because there is no way to distinguish between them. The example appears 
to be a US number without country code. But I don't know how you would 
know that. It could be a number in Bahrain. (It seems to be an *invalid* 
number in Bahrain, but unless you had a dialing plan for the entire 
world I don't know how you would know that.)

> Also, you may want to specify that the "punctuation" that E.164 permits is excluded (assuming you don't want dashes, commas, dots or spaces in the middle).

Or you could just allow it. No great shakes either way.

	Thanks,
	Paul

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 26 Sep 2012 00:03:42 +0100

On 25 Sep 2012, at 22:50, Paul Kyzivat wrote:
> RFC3108 *could* be valid without the '+' if it only permitted E.164 (global) numbers. But it claims to support both International Format E.164 numbers and private numbering plans. For that it is invalid because there is no way to distinguish between them. The example appears to be a US number without country code. But I don't know how you would know that. It could be a number in Bahrain. (It seems to be an *invalid* number in Bahrain, but unless you had a dialing plan for the entire world I don't know how you would know that.)
> 

To which I reply:

Hi Paul, folks,

Re. 3108 is psychic -- good point, well made.
We're wildly agreeing here.

All I was saying was that it's not the '+' that makes an E.164 number ->in International Format<-
(E.164 mentions International *and* National numbers [insofar as the ITU ever deals with national systems] -- it mentions Nationally Significant Numbers)

Trying to deal with both International and National/Local numbers is **really** hard, and impossible without context.
The same discussions came up during development of 3966 -- that's why there's a phone-context parameter for tel:, with a ["right-truncated"] International E.164 number [as an alternative to a domainname]).

As Paul sure knows, this has been done before. 3966 has extensive discussion on exactly the concerns Paul has rightly raised (and it's quite readable :).

3108 seems to have some secret unknown to the rest of us => ignore the magicians -- these two usages will never coexist without a reassuringly expensive gateway between these universes. That gateway will have to deal with context (although I don't want to answer the gateway RFI).

=> just nail down the meaning of E.164 number ("...in international format...", preceded by a '+' character), refer normatively to 3966's syntax, and we're done.
Anything more is thrashing over the same ground yet again.

atb,  Lawrence
p.s. intra-number punctuation should be simple, but (in particular, spaces) has bitten implementations more than once. I recommend applying cattle-prods to the programmers if they forget.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2012 00:25:41 -0400

I think we are in violent agreement.

Just to be clear, there are various ways to reference 3966 and use that 
in SDP CS. The ones that come to my mind are, when the <addrtype> is 
E164, require the <connection-address> to be:

1) 'global-phone-digits' from 3966, but excluding 'visual-separator' 
characters. (This is essentially what is currently specified.)

2) 'global-number' from 3966.

3) 'telephone-subscriber' from 3966.

Picking (3) will allow local-numbers with context to understand them.

I am inclined to recommend (3) because I can see no reason not to. Quite 
a lot of thought and discussion went into 3966, so why abandon or 
reinvent it?

	Thanks,
	Paul

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 26 Sep 2012 09:31:05 +0200

Hi Paul:

see inline comments.

> saying it means "local" without defining what "local" means is not a

Notice that "local without defining local" is what is currently in RFC 3108.

My proposal is to register E164 allowing international and 
non-international. The non-international could be used in local 
environments where there is no change of boundaries. This is like saying 
that, where both endpoints have agreed on the national boundary, the 
local representation could be used. This is what RFC 3108 tries to say.

>     Leave anything more to be done later if anyone

This is what the current version of the draft says, and I will be happy 
to accept it. But I understood Flemming had a problem.

>     trying to start from scratch.

We looked at it way back in time, and I believe the problem was 
understanding the a local number with a ";phone-context=foo" will be 
accepted as a valid parameter for an address in a c= line in SDP. It 
looks a bit strange, mostly by the presence of the semicolon.

Then, the telephone number in 3966 allows the representation of something 
more than digits, namely "#" and "*", which are not valid digits in E.164 
numbers.

So, we concluded that RFC 3966 was a good inspiration but not really what 
we are looking for.

BR,

      Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2012 10:48:55 -0400

On 9/26/12 3:31 AM, Miguel A. Garcia wrote:
>>> The problem, IMHO, lies in RFC 3108, because it allows both national
>>> and international numbering plans without separating the context.
>>>
>>> With or without the CS draft, RFC 3108 seems to have a problem. In
>>> spite of other problems (the draft fails to register E164 and perhaps
>>> some other parameters.
>>>
>>> As I said before, there is not foresee usage of the E164 number
>>> scheme in both RFC 3108 and SDP CS context. So, RFC 3108 can keep on
>>> using the mechanism they are currently using. The SDP CS draft will
>>> register the E164 with IANA with the syntax that may optionally
>>> include a plus sign. This does not affect current implementations of
>>> RFC 3108.
>>

Yes, I know. :-(

> non-international.

You mean those starting with '+' and those that don't right?
And those that don't are then really have "undefined" semantics, right?

> The non-international could be used in local

I don't understand *what* 3108 is *trying* to say.
But what it *does* say is ambiguous. And if you try to rationalize it 
with what you are proposing to register, then all the numbers used in 
3108 will be "local" numbers by the definition you register.

> to accept it. But I understood Flemming had a problem.

Maybe Flemming will weigh in again.

> looks a bit strange, mostly by the presence of the semicolon.

It may look a bit strange, but SDP allows a lot of strange things.

If you look at 4566, *none* of the forms being discussed are consistent 
with the existing ABNF (for <connection-field>, which currently must be 
either a <multicast-address> or <unicast-address> regardless of 
<nettype> or <addrtype>.

It is unfortunate that 4566 made provision for registering new <nettype> 
and <addrtype> values, and even stated that RFCs registering new 
<addrtype>s must give details of the syntax of the address. But it 
doesn't say if the syntax can be incompatible with <connection-field> or 
can only specify subsets of that. Probably the most important part of 
the c= syntax is that nettype, addrtype, and connection-field are 
separated by SP, and so perhaps by inference cannot contain SP.

As far as I can tell, all of <telephone-subscriber> is compatible (or 
not) with 4566 as 15 digits are.

> Then, the telephone number in 3966 allows the representation of
> something more than digits, namely "#" and "*", which are not valid
> digits in E.164 numbers.

While it allows them some places, it doesn't allow them in 
<global-number>, which is where E.164 numbers fall.

	Thanks,
	Paul

> So, we concluded that RFC 3966 was a good inspiration but not really
> what we are looking for.
>
> BR,
>
>       Miguel
>>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Sep 2012 16:52:30 -0400

> What is the single way that works for both?
Allow omission of the '+' sign for RFC 3108 compliant implementations 
(and possibly restrict that to ATM network type), but use the '+' prefix 
everywhere else.

> RFC 3108 doesn't support the '+' and purports to support both global 
> and local without it. But you can't really support both global and 
> local numbers without *some* non-numeric characters. (Unless you go 
> with dial strings, which are themselves not global.)
>
I believe the issue you are bringing up is one that is internal to RFC 
3108, which is how do you distinguish between a private and an 
International number in RFC 3108 ? I agree that's not clear, however 
that doesn't mean that you should disallow the syntax that has been 
defined there for international numbers, and which may be present in a 
number of current implementations.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Sep 2012 16:56:55 -0400

> numbers starting with '+'.
The problem is we have a Standards Track RFC that already defined that 
value with a different format.

> But I do have a little trouble with this draft registering E164 in a 
> way that permits numbers without the '+'. The problem with doing this 
> is defining what it means - how to interpret the number in that case. 
> Just saying it means "local" without defining what "local" means is 
> not a good thing.
>
It could be either International or Local, and I agree there is lack of 
adequate syntax definition to make a clear distinction between the two 
based on the RFC 3108 definition.

>   Leave anything more to be done later if anyone
RFC 3108 cares (and it's Standards Track).

>   trying to start from scratch.
In an ideal world, I'd agree with that, however neither RFC 3108 nor 
3GPP will presumably be happy with this.

-- Flemming

> Either of these work for me, though I would slightly prefer 
> referencing RFC3966, because it gives a more robust definition.
>
>     Thanks,
>     Paul
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Sep 2012 17:08:20 -0400

Hi Lawrence

On 9/25/12 5:27 PM, Lawrence Conroy wrote:
> National/Local numbers are not necessarily the same as dial strings
Agreed.
> (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be a number rather than any old dial string (with or without the preceding '9', with or without a carrier prefix, with or without a trunk "access" digit, ...).
Agreed.
> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. IIRC, the '+' comes from 3GPP and from TIA specs.
It's defined in ITU-T Recommendation E.123.
> Also, you may want to specify that the "punctuation" that E.164 permits is excluded (assuming you don't want dashes, commas, dots or spaces in the middle).
I think that's covered by the ABNF.

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2012 17:09:53 -0400

> number of current implementations.

If that is your goal, then I think the right answer is to define 
addrtype E164 within nettype PSTN, and say nothing about addrtype E164 
within nettype ATM. Note that 4566 says:

    New address types ("addrtype") may be registered with IANA.  An
    address type is only meaningful in the context of a network type, and
    any registration of an address type MUST specify a registered network
    type or be submitted along with a network type registration. ...

So I see no reason for *this* draft to register E164 for nettype ATM.

Then it will be up to somebody else to revise 3108 to deal with its 
issues and register nettype ATM and addrtype E164 within that.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Sep 2012 17:24:40 -0400

I tend to agree that option 3 is the technically best one, however 
please note, that part of the challenge we have here is
a) RFC 3108 is a Standards Track RFC that has been out for quote a while 
with a syntax that differs from what you suggest.
b) SDP-CS has been used by 3GPP for quite a while with a syntax that 
differs from RFC 3108 as well as RFC 3966 (to varying degrees per your 
note below).

The original "compromise" proposal was trying to address the above two 
points. Do you have any thoughts around other solutions that takes that 
into account ?

Thanks

-- Flemming

On 9/26/12 12:25 AM, Paul Kyzivat wrote:
> Just to be clear, there are various ways to reference 3966 and use 
> that in SDP CS. The ones that come to my mind are, when the <addrtype> 
> is E164, require the <connection-address> to be:
>
> I am inclined to recommend (3) because I can see no reason not to. 
> Quite a lot of thought and discussion went into 3966, so why abandon 
> or reinvent it?
>
>     Thanks,
>     Paul
>
>>>>   Me too. Personally, I would STRONGLY prefer that folks pulled the 
>>>> definition from 3966 (whichever of the two choices you make).
>>>>
>>>> See the last para of RFC4415 section 3 for the appropriate syntax 
>>>> references to RFC3966 -- yes, you DO need to refer to that, and I'd 
>>>> suggest normatively.
>>>> (as Paul has spelt out before, IIRC). I ASSUME that you intend this 
>>>> to be a number rather than any old dial string (with or without the 
>>>> preceding '9', with or without a carrier prefix, with or without a 
>>>> trunk "access" digit, ...).
>>>> That's why we strongly discouraged anything other than global 
>>>> numbers -- otherwise you're building in yet another "NAT" problem.
>>>>
>>>> See the text in the 2nd para of the intro to RFC6116 for the 
>>>> "anointed" spec/definition we used for "E.164 number".
>>>> BTW, E.164 doesn't include the '+', which is why RFC3108 is valid. 
>>>> IIRC, the '+' comes from 3GPP and from TIA specs.
>>>
>>> because there is no way to distinguish between them. The example 
>>> appears to be a US number without country code. But I don't know how 
>>> you would know that. It could be a number in Bahrain. (It seems to 
>>> be an *invalid* number in Bahrain, but unless you had a dialing plan 
>>> for the entire world I don't know how you would know that.)
>>>
>>>> Also, you may want to specify that the "punctuation" that E.164 
>>>> permits is excluded (assuming you don't want dashes, commas, dots 
>>>> or spaces in the middle).
>>>
>> (E.164 mentions International *and* National numbers [insofar as the 
>> ITU ever deals with national systems] -- it mentions Nationally 
>> Significant Numbers)
>>
>> Trying to deal with both International and National/Local numbers is 
>> **really** hard, and impossible without context.
>> The same discussions came up during development of 3966 -- that's why 
>> there's a phone-context parameter for tel:, with a 
>> ["right-truncated"] International E.164 number [as an alternative to 
>> a domainname]).
>>
>> As Paul sure knows, this has been done before. 3966 has extensive 
>> discussion on exactly the concerns Paul has rightly raised (and it's 
>> quite readable :).
>>
>> 3108 seems to have some secret unknown to the rest of us => ignore 
>> the magicians -- these two usages will never coexist without a 
>> reassuringly expensive gateway between these universes. That gateway 
>> will have to deal with context (although I don't want to answer the 
>> gateway RFI).
>>
>> => just nail down the meaning of E.164 number ("...in international 
>> format...", preceded by a '+' character), refer normatively to 3966's 
>> syntax, and we're done.
>> p.s. intra-number punctuation should be simple, but (in particular, 
>> spaces) has bitten implementations more than once. I recommend 
>> applying cattle-prods to the programmers if they forget.
>>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 26 Sep 2012 17:38:47 -0400

> So I see no reason for *this* draft to register E164 for nettype ATM.
Ahh - I had indeed missed that, and it appears the IANA registry is not 
structured this way either (addrtype registration is not associated with 
a network type). We should get that fixed as part of this. I'll also 
suggest that for RFC4566bis, we should update the IANA registration 
procedure to make that clear (MUST always specify a combination of 
network type and addrtype when registering a new addrtype).

With that important clarification in mind, I have no issue with 
registering "PSTN E164" and always requiring a "+" sign (and we can then 
discuss separately to what extent we want to conform with RFC 3966 
syntax, or just keep the current simple "1*15DIGIT" syntax.

> issues and register nettype ATM and addrtype E164 within that.
Sounds good. Thanks Paul

-- Flemming

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 27 Sep 2012 07:32:04 +0200

Hi Paul, thanks for your comments, inline answers.

> You mean those starting with '+' and those that don't right?

Exactly

> And those that don't are then really have "undefined" semantics, right?

Exactly. We can say that documents using the local format should indicate 
how to get the phone context.

> I don't understand *what* 3108 is *trying* to say.

That makes two of us :-)

> 3108 will be "local" numbers by the definition you register.

Yes. But whatever we do is not going to affect existing implementations 
of RFC 3108.

> either a <multicast-address> or <unicast-address> regardless of

Right, that is RFC 4566. The CS SDP draft extends 4566 by adding an 
e164-address. This is specified in the ABNF:

            connection-address /=  e164-address / "-"
            e164-address       =  "+" 1*15DIGIT
            ; DIGIT is specified in RFC 5234

> separated by SP, and so perhaps by inference cannot contain SP.

Yeap, that makes sense.

> not) with 4566 as 15 digits are.

Ok... so your proposal would be that the CS draft defines 
connection-address like this:

            connection-address /=  telephone-subscriber / "-"
                                ; telephone-susbscriber defined in
                                ; RFC 3966

If we are using the international format, this does not change anything 
with respect to the existing CS draft.

If we are using the national format, a ";phone-context" is required

I believe this works for the CS draft. But I don't know how RFC 3108 
stays now.

Do we have other views?

> <global-number>, which is where E.164 numbers fall.

Oops, I didn't realize about this subtle detail. Yes, a closer look at 
the syntax revealed what you said. So, then I can go with the proposal of 
the CS draft referring to RFC 3966.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 27 Sep 2012 07:45:37 +0200

As an author of the document, I can accept option 3 below.

This means that the connection-address will be specified in the CS draft as:

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: <[email-masked]>
Date: Thu, 27 Sep 2012 08:17:08 +0000

See [SV] below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Miguel A. Garcia
Sent: 27. syyskuuta 2012 8:46
To: Paul Kyzivat
Cc: Lawrence Conroy; [email-masked]
Subject: Re: [MMUSIC] Issue with E164 numbers in SDP CS draft

/Miguel

[SV] So would this work:
- we define the connection-address in SDP CS draft as per Miguel's suggestion above
- we register the E.164 addrtype with IANA in the SDP CS draft; it will be in the context of PSTN nettype so it doesn't clash with whatever is specified (or left unspecified) in RFC3108
- we add text to SDP CS draft that implementations MUST use global-number of RFC3966 if a global representation is available; otherwise a local-number may be used 

Simo

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 27 Sep 2012 15:23:46 +0200

> - we add text to SDP CS draft that implementations MUST use global-number of RFC3966 if a global representation is available; otherwise a local-number may be used

Yes, that is the current proposal.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 27 Sep 2012 15:44:47 +0200

To add a few thoughts to the debate:

RFC 3108 seems to define a general structure for the c= line

	c=<networkType> <addressType> <address>

But then every sentence beyond that seems to give requirements that only apply with the <networkType> is ATM.

So at least to me, where the <networkType> is PSTN, no additional constraints apply directly from RFC 3108 unless we say exactly how they do so. Moreover, we can ignore RFC 3108 beyond the general structure if we wish to do so.

I would support a structure that is always + followed by digits. 

I would note that E.164 does not include additional characters. That is introduced (like the "+") by E.123 which is there for the textual representation of E.164 numbers. Further that does not use "-" within numbers which is an americanism.

I do not particularly like the idea of adding such additional characters to the number (beyond the +) - I would prefer to see a straight digit string, which would be the the characters extracted from, or entered into, the related PSTN signaling, which does not include such characters.

So a specification that merely says "+" followed by digits as represented by the international telecommunication number as defined in E.164 would be sufficient for me.

If we follow RFC 3966, then it would have to be limited to global numbers. RFC 3966 is then inconsistent, because the text says it follows the rules of E.164, and then the ABNF defines visual separators, which are not defined in E.164.

Keith

> Of [email-masked]
> Sent: 27 September 2012 09:17
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Of ext Miguel A. Garcia
> - we register the E.164 addrtype with IANA in the SDP CS draft; it will be
> in the context of PSTN nettype so it doesn't clash with whatever is
> specified (or left unspecified) in RFC3108
> - we add text to SDP CS draft that implementations MUST use global-number
> of RFC3966 if a global representation is available; otherwise a local-
> number may be used
> 
> Simo
> 
> 
> (as Paul has spelt out before, IIRC). I ASSUME that you intend this to be
> a number rather than any old dial string (with or without the preceding
> '9', with or without a carrier prefix, with or without a trunk "access"
> digit, ...).
> >>>> That's why we strongly discouraged anything other than global numbers
> -- otherwise you're building in yet another "NAT" problem.
> >>>>
> permits is excluded (assuming you don't want dashes, commas, dots or
> spaces in the middle).
> >>>
> there's a phone-context parameter for tel:, with a ["right-truncated"]
> International E.164 number [as an alternative to a domainname]).
> >>
> discussion on exactly the concerns Paul has rightly raised (and it's quite
> readable :).
> >>
> >> 3108 seems to have some secret unknown to the rest of us => ignore the
> magicians -- these two usages will never coexist without a reassuringly
> expensive gateway between these universes. That gateway will have to deal
> with context (although I don't want to answer the gateway RFI).
> >>
> spaces) has bitten implementations more than once. I recommend applying
> cattle-prods to the programmers if they forget.
> >>
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Sep 2012 15:32:09 -0400

> I do not particularly like the idea of adding such additional characters to the number (beyond the +) - I would prefer to see a straight digit string, which would be the the characters extracted fr…

I don't have any particular issue with excluding <visual-separator> 
characters, other than concern with how to specify that.

IMO it is preferable to reference syntax defined in 3966 rather than 
respecify it. It is hard to do that and still exclude the 
visual-separators. If need be it can probably be done informally in English.

> So a specification that merely says "+" followed by digits as represented by the international telecommunication number as defined in E.164 would be sufficient for me.

Perhaps that would do, if there is an explicit goal to be that 
restrictive. That is equivalent to specifying that it must match 
<global-number-digits> from 3966, except the latter permits 
visual-separators.

Is there a concern here about allowing the more general representation 
of <telephone-subscriber>? If so, what is the concern? The ones I can 
think of are:

- more complex syntax to parse

   While true, it's not rocket science. So is this a real concern?
   Also it should be possible to parse a subset and ignore/reject
   the rest. More on this later.

- possibility that the caller may not understand or know how
   to use parameters on a global number.

   A simple answer here is that if you don't understand the
   parameters then a CS bearer can't be established.

   If you don't understand *any* parameters, then you may
   give up on the CS bearer as soon as you encounter a ";"
   without needing to parse the rest.

- possibility that the caller may not understand or be able
   to call a local number

   Same as above. If you don't support local numbers then
   give up.

- backward compatibility with deployments of early drafts

   (You know my opinion of this as an argument.)

I see one issue above, but it isn't really a *new* issue - it exists 
even as the draft is now written:

If the offerer is elected to be the active party, but is unable to make 
a call to the number provided, then the answerer doesn't realize what 
the problem is. There is no discussion of this point, or what should be 
done to recover from it.

For instance, this could occur if the number provided is valid but not 
callable by the caller. (E.g. because the caller's service doesn't 
include international calling.)

Local numbers, or global numbers with parameters, provide other ways 
that the caller may not be able to call the number. But they fall into 
the same category of issue.

> If we follow RFC 3966, then it would have to be limited to global numbers. RFC 3966 is then inconsistent, because the text says it follows the rules of E.164, and then the ABNF defines visual separ…

Why would it *have* to be limited to global numbers?

	Thanks,
	Paul

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 28 Sep 2012 08:23:11 +0200

Hi Keith, thanks for jumping into the discussion. See inline comments.

On 27/09/2012 15:44, DRAGE, Keith (Keith) wrote:
> But then every sentence beyond that seems to give requirements that
> only apply with the <networkType> is ATM.
>
> So at least to me, where the <networkType> is PSTN, no additional
> constraints apply directly from RFC 3108 unless we say exactly how
> they do so. Moreover, we can ignore RFC 3108 beyond the general
> structure if we wish to do so.
>

Agreed

> I would note that E.164 does not include additional characters. That
> is introduced (like the "+") by E.123 which is there for the textual
> representation of E.164 numbers. Further that does not use "-" within
> numbers which is an americanism.
>
> I do not particularly like the idea of adding such additional
> characters to the number (beyond the +) - I would prefer to see a
> straight digit string, which would be the the characters extracted
> from, or entered into, the related PSTN signaling, which does not
> include such characters.
>
> So a specification that merely says "+" followed by digits as
> represented by the international telecommunication number as defined
> in E.164 would be sufficient for me.
>
> If we follow RFC 3966, then it would have to be limited to global
> numbers. RFC 3966 is then inconsistent, because the text says it
> follows the rules of E.164, and then the ABNF defines visual
> separators, which are not defined in E.164.

So, if we refer to RFC 3966, then we ought to allow visual separators, 
which are already part of the specification. These visual separators 
include the following characters:

"-" / "." / "(" / ")"

Which might be ok when an E.164 number is represented for a human 
consumption. However, in the CS description draft this is supposed to be 
consumed by the endpoint. Additionally, the possibility of having visual 
separators in an E.164 number will break existing implementations.

My conclusion: if we refer to RFC 3966, but then we need to remove local 
numbers and visual separators, there is no point in adding such 
dependency. I prefer to refer the e164 address for this draft as a plus 
sign and a collection of digits.

BR,

       Miguel

>
> Keith
>
>
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked] Sent: 27 September 2012 09:17 To:
>> [email-masked]; [email-masked] Cc:
>> [email-masked]; [email-masked] Subject: Re: [MMUSIC] Issue
>> with E164 numbers in SDP CS draft
>>
>> See [SV] below.
>>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of ext Miguel A. Garcia
>> Sent: 27. syyskuuta 2012 8:46 To: Paul Kyzivat Cc: Lawrence Conroy;
>> [email-masked] Subject: Re: [MMUSIC] Issue with E164 numbers in SDP
>> CS draft
>>
>> connection-address /=  telephone-subscriber / "-" ;
>> telephone-susbscriber defined in ; RFC 3966
>>
>>
>> /Miguel
>>
>> [SV] So would this work: - we define the connection-address in SDP
>> CS draft as per Miguel's suggestion above - we register the E.164
>> addrtype with IANA in the SDP CS draft; it will be in the context of
>> PSTN nettype so it doesn't clash with whatever is specified (or left
>> unspecified) in RFC3108 - we add text to SDP CS draft that
>> implementations MUST use global-number of RFC3966 if a global
>> representation is available; otherwise a local- number may be used
>>
>> Simo
>>
>>
>>> Just to be clear, there are various ways to reference 3966 and
>>> use that in SDP CS. The ones that come to my mind are, when the
>>> <addrtype> is E164, require the <connection-address> to be:
>>>
>>> 1) 'global-phone-digits' from 3966, but excluding
>>> 'visual-separator' characters. (This is essentially what is
>>> currently specified.)
>>>
>>> I am inclined to recommend (3) because I can see no reason not
>>> to. Quite a lot of thought and discussion went into 3966, so why
>>> abandon or reinvent it?
>>>
>>> Thanks, Paul
>>>
>>>>>> Hi Folks, Me too. Personally, I would STRONGLY prefer that
>>>>>> folks pulled the
>>>>>> We had similar mantras to chant in ENUM, so I feel for the
>>>>>> squirming
>> here.
>>>>>>
>>>>> RFC3108 *could* be valid without the '+' if it only permitted
>>>>> E.164 (global) numbers. But it claims to support both
>>>>> International Format E.164 numbers and private numbering
>>>>> plans. For that it is invalid because there is no way to
>>>>> distinguish between them. The example appears to be a US
>>>>> number without country code. But I don't know how you would
>>>>> know that. It could be a number in Bahrain. (It seems to be an
>>>>> *invalid* number in Bahrain, but unless you had a dialing
>>>>> plan for the entire world I don't know how you would know
>>>>> that.)
>>>>>
>>>>> Thanks, Paul
>>>>>> all the best, Lawrence
>>>> Re. 3108 is psychic -- good point, well made. We're wildly
>>>> agreeing here.
>>>>
>>>> All I was saying was that it's not the '+' that makes an E.164
>>>> number ->in International Format<- (E.164 mentions International
>>>> *and* National numbers [insofar as the ITU ever deals with
>>>> national systems] -- it mentions Nationally Significant
>>>> Numbers)
>>>>
>> magicians -- these two usages will never coexist without a
>> format...", preceded by a '+' character), refer normatively to
>> 3966's syntax, and we're done.
>>>> atb,  Lawrence p.s. intra-number punctuation should be simple,
>>>> but (in particular,
>>> _______________________________________________ mmusic mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>> _______________________________________________ mmusic mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________ mmusic mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain