Subject: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs

From: <[email-masked]>
Date: Thu, 15 Nov 2012 09:06:01 +0000

Hi Flemming, Paul, Keith, and all,

When going through http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt for publication, Flemming had a comment on the format of global telephone numbers.

The draft currently says in Section 5.2.1:

  This memo exclusively uses the international representation of E.164
   numbers, i.e., those initiated with a '+' sign.  The syntax (see
   Section 5.7) refers to the representation of a 'global-number'
   construction already specified in RFC 3966 [RFC3966].  This
   representation requires the presence of the '+' sign.  Additionally,
   this representation allows for the presence of one or more 'visual-
   separator' constructions.  Implementations confirming to this
   specification and using the "E164" address type together with the
   "PSTN" network type MUST only use international E.164, i.e., those
   starting with a '+' sign and SHOULD NOT use visual-separators.

This was discussed earlier on the list, see  http://www.ietf.org/mail-archive/web/mmusic/current/msg09630.html

Flemming's comment was that referencing to RFC3966 but saying that the syntax is invalid because we only use parts of it is not a good idea.

The question is, could we just refer to RFC3966 and allow visual separators?

In my understanding the tradeoff is between slightly increased complexity in parser implementation versus being clear on the syntax. I would be inclined to prefer the latter.

Regards,
Simo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Nov 2012 09:56:16 -0500

On 11/15/12 4:06 AM, [email-masked] wrote:
> When going through
> http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt for
> publication, Flemming had a comment on the format of global telephone
> numbers.
>
> This was discussed earlier on the list, see
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09630.html
>
> Flemming’s comment was that referencing to RFC3966 but saying that the
> syntax is invalid because we only use parts of it is not a good idea.
>
> In my understanding the tradeoff is between slightly increased
> complexity in parser implementation versus being clear on the syntax. I
> would be inclined to prefer the latter.

My personal preference is, like yours, to go with 3966 and permit 
separators. IIRC the reason for text saying not to use separators was 
that some others were opposed to having them. (Early versions of the 
draft allowed only digits and didn't refer to 3966.)

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Nov 2012 10:51:19 -0500

On 11/15/12 4:06 AM, [email-masked] wrote:
> http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt 
> <http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt> for 
> Flemming's comment was that referencing to RFC3966 but saying that the 
To be clear, the "global-number" production in RFC 3966 allows for a 
number of parameters that are not part of the International E.164 format 
and thus I have two concerns with the current text
1) The visual-separator exclusion although the ABNF allows for it
2) The apparent disconnect between all of these optional extra 
parameters and the above text suggesting they are not allowed.

Thanks

-- Flemming

> complexity in parser implementation versus being clear on the syntax. 
> I would be inclined to prefer the latter.
>
> Regards,
>
> Simo
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Nov 2012 10:37:53 -0600

On 11/15/12 09:51, Flemming Andreasen wrote:
> number of parameters that are not part of the International E.164 
> format and thus I have two concerns with the current text

I don't think these really are issues. There are a lot of specifications 
where the ABNF would allow for certain productions, while the normative 
specification making use of that ABNF restricts those productions. For 
example, there is nothing in the ABNF of RFC 3261 that restricts SIP 
messages from having multiple CSeq header fields, although it doing so 
certainly isn't allowed.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Nov 2012 11:43:47 -0500

At end...

> parameters and the above text suggesting they are not allowed.

IIRC there was discussion on this. There are a number of symbols defined 
in 3966 that *could* be used here: telephone-subscriber, global-number, 
global-number-digits. All of them permit separators. Which one to choose 
depends on how much flexibility one wants to permit. The flexibility 
brings with it more parsing demands which people might object to if the 
flexibility will never be used.

I don't really care which one it is. global-number-digits is probably 
enough for common uses.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Nov 2012 12:58:30 -0500

On 11/15/12 11:37 AM, Adam Roach wrote:
> I don't think these really are issues. There are a lot of 
> specifications where the ABNF would allow for certain productions, 
> while the normative specification making use of that ABNF restricts 
> those productions. For example, there is nothing in the ABNF of RFC 
> 3261 that restricts SIP messages from having multiple CSeq header 
> fields, although it doing so certainly isn't allowed.
>

I think there is a big difference between having an ABNF that includes 
terminals and non-terminals in productions that may not be used at all 
as opposed to having an ABNF with certain semantic restrictions on what 
constitutes valid semantic values based on otherwise valid syntax. The 
former is generally well understood and accepted whereas the latter is 
not (and for good reason IMO - what's the point of having an ABNF 
otherwise ?).

-- Flemming

---

From: Adam Roach <[email-masked]>
Date: Thu, 15 Nov 2012 12:24:48 -0600

On 11/15/12 11:58, Flemming Andreasen wrote:
> as opposed to having an ABNF with certain semantic restrictions on 
> what constitutes valid semantic values based on otherwise valid 
> syntax. The former is generally well understood and accepted whereas 
> the latter is not (and for good reason IMO - what's the point of 
> having an ABNF otherwise ?).
You raise a good point. So, yeah, it looks like we probably want to take 
on an existing ABNF (with all its warts and optional things) or define 
our own (which would be trivial -- a plus sign followed by one or more 
digits is some of the most straightforward ABNF you'll ever see written).

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Nov 2012 15:09:36 -0500

> not (and for good reason IMO - what's the point of having an ABNF

Yes, I agree that this kind of constraint is a bit more of a stretch 
than the usual sort of things we revert to text for. (But I often have 
to make a tradeoff when constructing ABNF, between constraints that 
*can* be done syntactically with complex ANBF, and more forgiving ABNF 
and textual constraints.)

This is at least the third place I have come across in the last few 
months that had a need to represent a phone number, and where a 
reference into the 3966 ABNF could *almost* fit the bill. The last time 
was with TERQ. There I raised the possibility to Jon P that maybe it is 
time to revise 3966, so that it is more suited to being a source of 
definitions of phone number stuff that can be referenced. I have mixed 
feelings about that - I think it would be a good thing to do, but I 
don't know how many will consider it worth the trouble.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Nov 2012 15:16:18 -0500

> digits is some of the most straightforward ABNF you'll ever see written).

Yes, that is where this draft started. (Without the "+".) Certainly it 
would "work". But it seems wrong to me. There ought to be an 
authoritative source for the syntax.

Also, I wonder if some of that extra syntax might actually be useful in 
getting the CS call established in special situations. Maybe even local 
numbers might be useful in some situations.

I'll admit that the separators are not *necessary* in any case. But 
forbidding those might just mean that the application will need to add 
code to strip them from whatever source it uses for its local number. At 
least this way its better defined what should be stripped.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Mon, 19 Nov 2012 10:05:00 +0000

See at the end.

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: 15. marraskuuta 2012 22:16
To: Adam Roach
Cc: Flemming Andreasen; Veikkolainen Simo (Nokia-CTO/Espoo); [email-masked]; [email-masked]
Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs

On 11/15/12 1:24 PM, Adam Roach wrote:
>> I think there is a big difference between having an ABNF that 
>> includes terminals and non-terminals in productions that may not be 
>> used at all as opposed to having an ABNF with certain semantic 
>> restrictions on what constitutes valid semantic values based on 
>> otherwise valid syntax. The former is generally well understood and 
>> accepted whereas the latter is not (and for good reason IMO - what's 
>> the point of having an ABNF otherwise ?).
> You raise a good point. So, yeah, it looks like we probably want to 
> take on an existing ABNF (with all its warts and optional things) or 
> define our own (which would be trivial -- a plus sign followed by one 
> or more digits is some of the most straightforward ABNF you'll ever see written).

Yes, that is where this draft started. (Without the "+".) Certainly it would "work". But it seems wrong to me. There ought to be an authoritative source for the syntax.

Also, I wonder if some of that extra syntax might actually be useful in getting the CS call established in special situations. Maybe even local numbers might be useful in some situations.

I'll admit that the separators are not *necessary* in any case. But forbidding those might just mean that the application will need to add code to strip them from whatever source it uses for its local number. At least this way its better defined what should be stripped.

[Simo] Referencing RFC3966 can be done in several ways: reusing the entire telephone-uri definition, the global-number, or only the global-number-digits (which allows visual separators). What the draft is using the number for (correlation of SDP with a CS call), just referencing the global-number-digits part would suffice. However, global-number allows parameters to be added to global-number-digits, which I agree might be useful in some scenarios - basic interoperability would be achieved by parsing the global-number-digits portion. local-number in RFC3966 include things like HEXDIG, "*" and "#" which I don't think provide much additional help in achieving our goal.

-Simo

	Thanks,
	Paul