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

"Miguel A. Garcia" <> Wed, 20 July 2011 06:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A339721F886A for <>; Tue, 19 Jul 2011 23:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.58
X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FHZFloBmQPk9 for <>; Tue, 19 Jul 2011 23:13:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CDE3421F8544 for <>; Tue, 19 Jul 2011 23:13:24 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-0e-4e267203e7ae
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 36.43.20773.302762E4; Wed, 20 Jul 2011 08:13:23 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 20 Jul 2011 08:13:22 +0200
Message-ID: <>
Date: Wed, 20 Jul 2011 08:13:22 +0200
From: "Miguel A. Garcia" <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Robert Sparks <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: Dan Burnett <>, Saravanan Shanmugham <>, Dave Oran <>, General Area Review Team <>, Eric Burger <>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-speechsc-mrcpv2-24.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jul 2011 06:13:25 -0000

On 19/07/2011 21:08, Robert Sparks wrote:
> 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

Ok, I understand your motivation. Let's keep the draft as is in this aspect.


Miguel A. Garcia
Ericsson Spain