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

[<[e-mail]>]

See at the end.

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

On 11/15/12 1:24 PM, Adam Roach wrote:
> On 11/15/12 11:58, Flemming Andreasen wrote:
>>
>> 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 ?).
> 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