Re: [Gen-art] Gen-ART review of draft-ietf-speechsc-mrcpv2-24.txt

Robert Sparks <rjsparks@nostrum.com> Tue, 19 July 2011 19:08 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BAD11E807F for <gen-art@ietfa.amsl.com>; Tue, 19 Jul 2011 12:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 TpDgqN4-R4ml for <gen-art@ietfa.amsl.com>; Tue, 19 Jul 2011 12:08:17 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 93AEA11E807A for <gen-art@ietf.org>; Tue, 19 Jul 2011 12:08:16 -0700 (PDT)
Received: from [192.168.2.105] (pool-173-71-50-10.dllstx.fios.verizon.net [173.71.50.10]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6JJ8Bnm094634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2011 14:08:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <4E2531D4.7080900@ericsson.com>
Date: Tue, 19 Jul 2011 14:08:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8E1797F-2FAA-4CBA-945A-20C28A1A5588@nostrum.com>
References: <4DBFA327.7070404@ericsson.com> <656E03F7-D6C2-42F3-BBFB-EAC6C9C1CDA1@voxeo.com> <4E2531D4.7080900@ericsson.com>
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass (nostrum.com: 173.71.50.10 is authenticated by a trusted mechanism)
Cc: Dan Burnett <dburnett@voxeo.com>, Saravanan Shanmugham <sarvi@cisco.com>, Dave Oran <oran@cisco.com>, General Area Review Team <gen-art@ietf.org>, Eric Burger <eburger@standardstrack.com>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-speechsc-mrcpv2-24.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2011 19:08:17 -0000

Replying to just one part
On Jul 19, 2011, at 2:27 AM, Miguel A. Garcia wrote:

>>> - Section 4.2 reads:
>>> 
>>> To remain backwards compatible with conventional SDP usage,
>>> the format field of the m-line MUST have the arbitrarily-selected
>>> value of "1".
>>> 
>>> The comment is that in other protocols, for example, MSRP [RFC4975] it
>>> has been selected to use an asterisk "*" in the format field. I wonder if
>>> it is possible to unify criteria, in order to allow usage of conventional
>>> SDP parsers.
>> 
>> I don't see how this has any relationship to "conventional SDP parsers".
>> Any SDP parser should be able to parse the value "1", and the allowed
>> value is protocol-specific anyway. Since the values of the media and
>> protocol fields are completely different in our case, and because this
>> would break existing implementations of MRCP, I see no sufficient reason
>> to change the value.
> 
> Let me give you an example. If I have an SDP class that encodes SDP, the class would not be able to decide whether to write an asterisk "*" or a "1" in the format field, when you invoke it. Writing "1" or "*" will be dependent on the application.
> 
> Then, if you see an SDP body captured by Wireshark or similar, you will need to know which application generated it before you could decided whether the SDP is correct or not. And Wireshark will not be able indicate "format is irrelevant" until it knows which application carried that SDP.
> 
> I haven't heard a good reason for keeping the value "1". So, I am still proposing to reuse the "*".

Miguel - your SDP class will have to ask the application what the <fmt> field means for a given <proto> field value _anyhow_ to populate it correctly.
Similarly, something like wireshark will have to recognize what is in the <proto> field to do any higher level of verification beyond
the basic syntax in 4566 (which is to match a token as 4566 defines token, and either * or 1 will match).

As Dan points out already there is deployed code that this change would break, and I don't see the benefit you are arguing for.

RjS