Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-media-capabilities-13

Flemming Andreasen <fandreas@cisco.com> Mon, 09 July 2012 14:52 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 8118C11E809A for <mmusic@ietfa.amsl.com>; Mon, 9 Jul 2012 07:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.998
X-Spam-Level:
X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4DhgqIxMRWH for <mmusic@ietfa.amsl.com>; Mon, 9 Jul 2012 07:52:04 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C35FF21F84B3 for <mmusic@ietf.org>; Mon, 9 Jul 2012 07:52:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=20317; q=dns/txt; s=iport; t=1341845549; x=1343055149; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Pn2YCbYc7z2R3COe6o0tScpxRKTCyrpZPEZZ8kb71GU=; b=ddNoaCkGr/Fb0AtdtUre7uX0ZA5dmjc5+GDXa2EohASA9u6b+1/eXA1c ls+Jd857Cf+04gbtnZZJYi6YcO0iK1+CrHxQpaG7Tad7w3IH8ip77pn2W aFdZcfhLNEt2rHl5OylcqoVNohhKm7vzHTyKoHPjVs6XDnzYND1o80Aox 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFAODu+k+tJXHA/2dsb2JhbABFgkqIe6hCg2SBB4IgAQEBBBIBGkwQCxgJFw4PAkYGDQEHAQEeh2ubUp9ikUwDlTaOH4Fmgns
X-IronPort-AV: E=Sophos; i="4.77,552,1336348800"; d="scan'208,217"; a="100034413"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jul 2012 14:52:28 +0000
Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q69EqRHP005394; Mon, 9 Jul 2012 14:52:27 GMT
Message-ID: <4FFAF035.40401@cisco.com>
Date: Mon, 09 Jul 2012 10:52:37 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5@ESESSCMS0356.eemea.ericsson.se>
Content-Type: multipart/alternative; boundary="------------010105030009030708030808"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-media-capabilities-13
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: Mon, 09 Jul 2012 14:52:08 -0000

Hi Christer

Thank you for the review comments - feedback below


On 4/30/12 8:27 AM, Christer Holmberg wrote:
>
> Hi,
>
> Eventhough a very detailed mechanism, in the same way as Cullen I 
> could not come up with cases where the mechanism would not work.
>
> I also took a detailed look at the ABNF, where I have some comments.
>
> -----------------
>
> General:
>
> SDP normally has a rather strict syntax. For example, elements are 
> normally separated explicitly with "SP". However, you use "1*WSP" in 
> most places. Is there a reason for having a more relaxed syntax in 
> media cap?
>
Not really, but I have never understood why a text-based protocol should 
choke on white-space. There is a well-defined grammar, so I don't really 
see any reason to change (not least since you'd change to something less 
liberal).

> ----------------
>
>   
> Section 3.3.2.1:
>   
> The section contains examples with a number of rmcap attributes:
>   
>         a=rmcap:1,2 audio G729/8000
>         a=rmcap:1 video H263-1998/90000
>         a=rmcap:2 video H263-2000/90000
>   
> However, I don't think these are valid according to the syntax in section 3.3.1, which does not define the media type ("audio", "video", etc):
>   
>                 a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate> [/<encoding-parms>]
>   

Good catch - fixed.
>   
> ---------------
>   
>   
> Section 3.3.8:
>   
> The example contains the following line:
>   
>                 a=rmcap:51 *
>   
> However, I don't think that is valid according to the syntax in section 3.3.1, which mandates both encoding name and clock-rate:
>   
>                 a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate> [/<encoding-parms>]
>   
>   
> In addition, I find no definition of using "*" for the encoding-name (I assume it is some kind of wildcard).
>   
Outstanding catch :-)

Fixed (to "omcap", which clarifies use of "*" as well)
>   
> ---------------
>   
>   
> Section 4.1:
>   
> See issue on 3.3.8.
>   

Sorry - I don't see the corresponding issue in 4.1. Can you elaborate ?

>   
> ---------------
>   
>   
> a=omcap:
>   
> There is no example showing the a=omcap attribute. I think it would be good to have one.
>   
Expanded example in Section 4.3 to cover omcap.
>   
> ---------------
>   
>   
> a=sescap:
>   
> There is no example showing the usage of optional-configs. I think it would be good to have one.
>   
I changed one of the examples in Section 3.3.8 to illustrate this.

Thanks

-- Flemming


>   
> ---------------
>   
>
> Regards,
>
> Christer
>