Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 13 August 2014 14:47 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842201A0700 for <mmusic@ietfa.amsl.com>; Wed, 13 Aug 2014 07:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.965
X-Spam-Level: *
X-Spam-Status: No, score=1.965 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTuxpO811XMJ for <mmusic@ietfa.amsl.com>; Wed, 13 Aug 2014 07:47:34 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 347B71A020B for <mmusic@ietf.org>; Wed, 13 Aug 2014 07:47:34 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id eCmw1o0091GhbT855EnZoY; Wed, 13 Aug 2014 14:47:33 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id eEnZ1o00c3ZTu2S3TEnZyk; Wed, 13 Aug 2014 14:47:33 +0000
Message-ID: <53EB7A85.9050107@alum.mit.edu>
Date: Wed, 13 Aug 2014 10:47:33 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Fredrik Bergholtz <fredrik.bergholtz@sverigesradio.se>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <53E93F39.5090401@alum.mit.edu> <53EA3B69.8090902@alum.mit.edu> <6A5A8D4EF65AF1439301480747E29F434E431EB2@STOEXMBX01.sr.se>
In-Reply-To: <6A5A8D4EF65AF1439301480747E29F434E431EB2@STOEXMBX01.sr.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407941253; bh=hA2IFddvlvCKnzHpkv5ZDc1MrZyMP8EJd/FqGxYB7To=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mxfUEC6QP7AbYfaNE/6iuHpiZLokhuiICtglZOQRMXi+ROduTyVJYCmNOi4XrCdzK OGjay27W23sC9LMyXC63bm8XMsOJsq+8udsH7Ik+UD+d9k2WovAdrFiZ5AcjbguKvy kFnPPVx2VK24BtIinjqZ6SZ/C84eZhh1DnCEIXt25ShRqDEme1FuaK2Xi1YhVrtMaS iKcDIeuW/5cPCRczc4VUzA2ta2j2XXUkOSj+nVp1iXWxeccPVrdH46iqt7bCE9qKSg 4Z6rr637hz/H36uwjXUbVf7HzyTTCNOIFi7laQKH5uuk6LbR7w4Eg3HJtCzSqgddnh Q7b+BQ7Q7pQxA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UY6ckfwvM77ykP0ADWu_iAKuNxI
Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 13 Aug 2014 14:47:37 -0000

On 8/13/14 7:37 AM, Fredrik Bergholtz wrote:
> Good job.
>
> I wonder if it would be wrong or bad to change
>
>      fmtp-value = fmt SP format-specific-params
>
> to
>
>      fmtp-value = payload-type SP format-specific-params
>
> thus using the definition of payload-type from a=rtpmap rather than adding a new definition of fmt that would, as I understand it, be essentially the same.

That would be wrong.

The definition of each <proto> gets to constrain the syntax of the <fmt> 
values allowed with it. The RTP family of <proto> values require that 
the <fmt> values be integers. So when those same values show up in 
rtpmap, they are still constrained to be integers, because rtpmap is 
only used in those cases.

OTOH, fmtmap may be used with any <proto> type, so it must allow the 
more general value.

> Another issue is that I know of one "extension" that would become invalid if this syntax for a=ptime is introduced. This extension is not yet an official extension of SDP but the standard is accepted as of 2013 within Audio Engineering Society (AES). Section 8.1 of AES67-2013 states:
>
>      8.1 Packet time
>      Packet time is described with two SDP attributes defined in RFC 4566.
>
>          a=ptime <milliseconds>[.<milliseconds decimal>]
>          a=maxptime <milliseconds>[.<milliseconds decimal>]
>
>      Signaled packet time multiplied by sampling frequency rounded to the nearest integer indicates the number of
>      samples in each packet. The packet time descriptions shall be given with error less than half a sample period so
>      that the calculated number of samples per packet rounds to the intended integer value. In many cases, this
>      requires the inclusion of the <milliseconds decimal> in the description.
>
> If SDP is to allow that kind of usage, the type for ptime, and possibly also maxptime, should be the positive-real-number definition as used in a=framerate:
>
>      packet-time = positive-real-number

If this is being proposed as an *extension*, what provision is being 
made for backward compatibility? I suspect many implementations won't 
accept a fractional value.

> Concerning the questions about adding range limits on values, I think that only if the value references something that is range- limited by specification, such as RTP payload type, should the SDP specify a matching range limitation. This means that the integer of the payload-type should be limited to a seven bit, unsigned integer. The other class of values would be values that are limited only by implementation. Among these I count packet times, clock rates, frame rates etc. For these values I would prefer that SDP does not limit the ranges.

I'm not inclined to impose the range in *syntax*.
We can specify it as a semantic constraint, but should probably be 
careful about when we do this. So I'm looking for opinions about when it 
is important to specify this and when it is not - on a case by case basis.

	Thanks,
	Paul

> Best regards
> Fredrik Bergholtz
> Swedish Radio
>
>
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: den 12 augusti 2014 18:06
>> To: mmusic@ietf.org
>> Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED
>>
>> I made some corrections based on offline comments from Christian Groves.
>> Revised version attached.
>>
>> 	Thanks,
>> 	Paul
>>
>> On 8/11/14 6:10 PM, Paul Kyzivat wrote:
>>> I took an action item to make a proposal for the syntax of attributes
>>> in 4566bis.
>>>
>>> I've *started* on it, and have enough that I would like to get some
>>> feedback before going further.
>>>
>>> Attached is a snippet from section 6 of 4566bis (SDP Attributes) to
>>> which I have added some ABNF syntax for just the values. (Each
>>> addition starts with "Syntax:")
>>>
>>> This isn't necessarily the *form* it will take when done. For now what
>>> I'm looking for is feedback on the substance.
>>>
>>> Of particular concern - when the format has text values, should those
>>> be case-sensitive (the default for SDP), or case-insensitive? I think
>>> we need to sort this out by what the common usage is.
>>>
>>>       Thanks,
>>>       Paul
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>
>