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

Flemming Andreasen <fandreas@cisco.com> Thu, 15 November 2012 17:58 UTC

Return-Path: <fandreas@cisco.com>
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 47C9921F8947 for <mmusic@ietfa.amsl.com>; Thu, 15 Nov 2012 09:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.548
X-Spam-Level:
X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 GoiEhL+cCUgY for <mmusic@ietfa.amsl.com>; Thu, 15 Nov 2012 09:58:33 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49D21F88A9 for <mmusic@ietf.org>; Thu, 15 Nov 2012 09:58:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4162; q=dns/txt; s=iport; t=1353002312; x=1354211912; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7hmK5UoEhGPJsuRBk7/ezu5QkCIrxvnquIuNlRNXGxM=; b=QV3xwTMnLXqYKJiADm0PQm1a0JUVVjXdaIHPe+IEy8yngCFR6sjY94GG uMBmlOnMJdSOaRxugT9j5UeUf6/9ppyZltt6fY9Xhu6wAJGug03Onr0SG nLNkqN8lnS1t4ET5TT4OH6Q340iViZnNyGR6BNyxJADC/+BxjlGPraFJt c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Al8FAKMspVCtJXG+/2dsb2JhbABEi3yyfINEgQiCHgEBAQQSAWUBEAsEFAkWDwkDAgECAUUGDQEHAQEeh2ucfaAJkl0DiFqNIo5YgWuDDQ
X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="142649505"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 15 Nov 2012 17:58:32 +0000
Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFHwUFL002978; Thu, 15 Nov 2012 17:58:31 GMT
Message-ID: <50A52D46.5020803@cisco.com>
Date: Thu, 15 Nov 2012 12:58:30 -0500
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
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>
In-Reply-To: <50A51A61.1070905@nostrum.com>
Content-Type: multipart/alternative; boundary="------------030504080208070505050003"
Cc: keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org, pkyzivat@alum.mit.edu
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 17:58:34 -0000

On 11/15/12 11:37 AM, Adam Roach wrote:
> On 11/15/12 09:51, Flemming Andreasen wrote:
>> 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.
>
> 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

> /a