Re: [MMUSIC] draft-pthatcher-mmusic-rid-02

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 19 October 2015 22:31 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 C5C551B2D8E for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 15:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 pydcvyU09mlP for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 15:31:35 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3B51B2D80 for <mmusic@ietf.org>; Mon, 19 Oct 2015 15:31:34 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-05v.sys.comcast.net with comcast id XAXS1r00327uzMh01AXapF; Mon, 19 Oct 2015 22:31:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id XAXZ1r00K3Ge9ey01AXZUS; Mon, 19 Oct 2015 22:31:34 +0000
To: mmusic@ietf.org
References: <56202075.3000202@nostrum.com> <56255D44.7050301@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56256F45.2060608@alum.mit.edu>
Date: Mon, 19 Oct 2015 18:31:33 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56255D44.7050301@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445293894; bh=cwASpva5v/dERjfKMzIQiDyjJc31qU+andNCvhxqPUI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ZyeisDclo7g8q/zYv1iynoGU0/FnR0yqmefeHomgMB62IP85U4EUAwr3KdY4e99+q fSwk1AUVzHhYEXLtJfObX1vY5LCq/4Q75hr05wYbAWbWAHA6P9kqXj3Dejoiqg3DMS WVYU6qfqjmscIe1IJtZnYCzRrURN6PMCnzd435AvIhnV7iFnQuLj5pCDFOeh6MMV9O FEkZdf5eELpOT1lxF6yCc657C5KZFmNATssAeo2hQd6qs6eGpumMxmH8S1lfHaRS5x USYgBK17U9zGEfVhCVE90uB7gbbsz2W46PFvG2Qdu5C/Zp8INqfqzzYr2ZDJzRdGM9 FAfA8mjuhzcgw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/r9eVU5DSIysHgZDVexZ6grBdFZI>
Subject: Re: [MMUSIC] draft-pthatcher-mmusic-rid-02
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: <https://mailarchive.ietf.org/arch/browse/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, 19 Oct 2015 22:31:36 -0000

Just a few comments on this version!

* Section 6:

    o  max-fs, for frame size in pixels per frame.  This is the product
       of frame width and frame height, in pixels, for rectangular
       frames.

Are non-rectangular frames possible? If so, what would this mean in that 
case? Does it mean:

- for rectangular frames the max-fs is the product of frame width and 
height, while it can also be used for non-rectangular frames, using some 
other algorithm?

- OR, does it mean that this can only be used for rectangular frames?

* Section 7.4.  (Offering Processing of the SDP Answer)

*Offering* processing??? Is this a spec for a church? :-)

I think you mean "Offer Processing".

Then:

        ... If the rid-
        level parameters are incompatible with the other codec
        properties, then the "a=rid" line is removed.

I don't think it works for the offerer to remove the rid at this point. 
The answerer thinks its answer was ok and use of rid is in effect. So 
some more drastic action is needed to get the two in sync.

	Thanks,
	Paul

On 10/19/15 5:14 PM, Adam Roach wrote:
> Based on feedback received on the -01 draft, I have updated the RID
> draft again:
>
> https://tools.ietf.org/html/draft-pthatcher-mmusic-rid-01
>
> Diffs from the previous version:
>
> https://tools.ietf.org/rfcdiff?url2=draft-pthatcher-mmusic-rid-02.txt
>
> And recognizing that this is moving fairly quickly, here's a diff from
> the -00 version:
>
> https://tools.ietf.org/rfcdiff?url1=draft-pthatcher-mmusic-rid-00.txt&url2=draft-pthatcher-mmusic-rid-02.txt
>
>
> [AVTEXT is copied on this email for their awareness of the SDES work
> described in this document -- please send any followups to MMUSIC]
>
> /a
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>