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

On 27/09/2012 15:44, DRAGE, Keith (Keith) wrote:
> 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.
>

Agreed

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

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: mmusic-bounces@ietf.org
>> [mailto:mmusic-bounces@ietf.org] On Behalf Of
>> Simo.Veikkolainen@nokia.com Sent: 27 September 2012 09:17 To:
>> Miguel.A.Garcia@ericsson.com; pkyzivat@alum.mit.edu Cc:
>> lconroy@insensate.co.uk; mmusic@ietf.org Subject: Re: [MMUSIC] Issue
>> with E164 numbers in SDP CS draft
>>
>> See [SV] below.
>>
>> -----Original Message----- From: mmusic-bounces@ietf.org
>> [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Miguel A. Garcia
>> Sent: 27. syyskuuta 2012 8:46 To: Paul Kyzivat Cc: Lawrence Conroy;
>> mmusic@ietf.org Subject: Re: [MMUSIC] Issue with E164 numbers in SDP
>> CS draft
>>
>> 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:
>>
>> 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
>>
>>
>> On 26/09/2012 6:25, Paul Kyzivat wrote:
>>> 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
>>>
>>> On 9/25/12 7:03 PM, Lawrence Conroy wrote:
>>>> On 25 Sep 2012, at 22:50, Paul Kyzivat wrote:
>>>>> On 9/25/12 5:27 PM, Lawrence Conroy wrote:
>>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>>> all the best, Lawrence
>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> _______________________________________________ mmusic mailing
>>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>> _______________________________________________ mmusic mailing list
>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________ mmusic mailing list
>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic

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