Re: [MMUSIC] Progressing the rid draft (RTP Payload Format Constraints)

Adam Roach <adam@nostrum.com> Fri, 05 February 2016 21:36 UTC

Return-Path: <adam@nostrum.com>
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 8C4E51B2CE9; Fri, 5 Feb 2016 13:36:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 EZgkKnimHTT8; Fri, 5 Feb 2016 13:36:29 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16D31B2CE1; Fri, 5 Feb 2016 13:36:28 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u15LaMZM059806 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 5 Feb 2016 15:36:23 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Peter Thatcher <pthatcher@google.com>, Flemming Andreasen <fandreas@cisco.com>
References: <566F2202.5010107@cisco.com> <CAJrXDUG0V13tS31Aeo_FwJYvFKOXthizSPwWd3bgOuPUwRWi4g@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <56B515D6.9090005@nostrum.com>
Date: Fri, 05 Feb 2016 15:36:22 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAJrXDUG0V13tS31Aeo_FwJYvFKOXthizSPwWd3bgOuPUwRWi4g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010800090404020006070309"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/t2uhZpTWNuBqK_nB-ELbqeHGwYA>
Cc: draft-ietf-mmusic-rid@ietf.org, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Progressing the rid draft (RTP Payload Format Constraints)
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: Fri, 05 Feb 2016 21:36:30 -0000

On 2/5/16 15:01, Peter Thatcher wrote:
> Having just re-read draft-ietf-mmusic-rid-02 from to top to bottom, I 
> think it's in a very good state.  I only have minor readability and 
> editorial comments where I think it could be improvements.

Thanks!

>  On small matters of readability:
>
> - We use the term "RID RTP streams", which is then defined in another 
> spec as "source RTP Streams".  Can we just call them "source RTP 
> streams" here too and save the reader some indirection?

But it's not exactly "a Source RTP Stream". It's "a Source RTP Rtream, 
*or* the non-redundant RTP Stream of a Dependent Stream," which is a bit 
too unwieldy to use all over the document.

This distinction between "Source RTP Stream" and "RID RTP Stream" is 
small but important. If you want to suggest a different term for this 
construct, I'm quite keen to have a more intuitive term. But I spent 
probably way too much time scratching my head over this without coming 
up with anything better than "RID RTP Stream".

You can argue that RFC 7576 should have defined a term that we could 
just use here, and I would heartily agree. But it didn't, and we've got 
to work with the terms as published.


> - We use the terms "constraints", "parameters" and even "constraining 
> parameters", which I believe all mean the same thing.  Can we just 
> pick one and save the reader some disambiguation?

I'll make a pass to clean this up. I'm going to go with "constraint" so 
as to avoid confusion with ftmp parameters.
> On the open issues:
>
> 11.1 (declarative SDP): I agree with keeping the current text.
>
> 11.2 (bitrate definition): I agree with keeping the current text.
>
> 11.3 (escaping values): I agree with option #3 (let a future extension 
> define it, if needed).
>
> 11.4 (max-width and max-height): Either way is fine to me (included or 
> not).
>
> 11.5 (max-fps definition): I agree with keeping the current text.

Thanks for explicitly commenting on the open issues. :)

> And finally, some very minor editoral things:
>
> - The sentence "All "rid" parameters MUST be registered ... Section 
> 12" doesn't have a period at the end.
>
> - The sentence "The SDP given below skips few lines" should be "The 
> SDP given below skips a few lines".
>

Good catches. Thanks.

/a