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

From: Peter Thatcher <[email-masked]>
Date: Fri, 5 Feb 2016 13:01:48 -0800

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.

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?

- 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?

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.

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".

On Mon, Dec 14, 2015 at 12:09 PM, Flemming Andreasen <[email-masked]>
wrote:

> Greetings MMUSIC
>
> As you know, we have an external dependency and a fairly aggressive
> timeline on the RTP Payload Format Constraints draft (
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/)
>
> We haven't seen much list traffic on this draft since the Yokohama meeting
> and hence would like to remind people to please take a look at and post any
> comments you may have on the draft. If you have read the current version of
> the draft and don't have any comments on it, we would like to hear about
> that too.
>
> Thanks
>
> -- Flemming (as MMUSIC co-chair)
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 5 Feb 2016 15:36:22 -0600

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!

> - 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.

> 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.
> 11.5 (max-fps definition): I agree with keeping the current text.

Thanks for explicitly commenting on the open issues. :)

> - 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

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 5 Feb 2016 13:44:28 -0800

> too unwieldy to use all over the document.

Oh yes, I forgot about that little wrinkle in the taxonomy.

​

> ​

> 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.
>

You're right.  Let's just s
tick
​with​
 "RID RTP Stream"
​.
​

> I'll make a pass to clean this up. I'm going to go with "constraint" so as
> to avoid confusion with ftmp parameters.
>

​Sounds good.
​