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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 15 November 2012 20:16 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BC421F8552 for <mmusic@ietfa.amsl.com>; Thu, 15 Nov 2012 12:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.393
X-Spam-Level:
X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9rRvFbYNohq for <mmusic@ietfa.amsl.com>; Thu, 15 Nov 2012 12:16:20 -0800 (PST)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 6069E21F857D for <mmusic@ietf.org>; Thu, 15 Nov 2012 12:16:20 -0800 (PST)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta02.westchester.pa.mail.comcast.net with comcast id PnQJ1k0090bG4ec51wGK7y; Thu, 15 Nov 2012 20:16:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id PwGK1k00m3ZTu2S3PwGKmQ; Thu, 15 Nov 2012 20:16:19 +0000
Message-ID: <50A54D92.9010108@alum.mit.edu>
Date: Thu, 15 Nov 2012 15:16:18 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
References: <D09DAE6B636851459F7575D146EFB54B1A3BD4C3@008-AM1MPN1-025.mgdnok.nokia.com> <50A50F77.7060906@cisco.com> <50A51A61.1070905@nostrum.com> <50A52D46.5020803@cisco.com> <50A53370.3010906@nostrum.com>
In-Reply-To: <50A53370.3010906@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Flemming Andreasen <fandreas@cisco.com>, keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org
Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 20:16:21 -0000

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.

	Thanks,
	Paul