Hi Qin, Roni, Thank you for comments. I've just updated our draft as draft-ietf-payload-rfc3189bis-03. See comments in-line please. > 1. Section 1: > > [Qin]: It looks this version extends RFC3189 to support some new features. > However I can not see any dependency to RFC3189 in the introduction section > until > I read the last section in this document, is it more straigtforward and > clear to merge the section 7,8 > to the introduction section and clarify how this document is different from > RFC3189. > > Roni: This document does not extend but obsolete RFC3189, so it should not > reference it. As for the difference from RFC3189 I think it is better to > have a separate section. Now, I keep the section by Roni's comment. > 2. Section 3.1.1 > > [Qin]: In section 7, you claim you have removed SMPTE 306M, since it is > covered by SMPTE 314M format. > However in section 3.1.2, the value for SMPTE 306M is still kept in the > encode list. So the question is > where do you remove SMPTE 306M in this document? Why SMPTE 306M in the media > type registration is still kept? > Does this conflict with what you said in the section 7? > > Roni: Maybe change the first bullet of section 7 > > " Removed SMPTE 306M, since it is covered by SMPTE 314M format" > > To > > "support for SMPTE 306M is only for backward interoperability, since it is > covered by SMPTE 314M format" I changed the sentence in 1st bullet of sec.7. > 3. Section 3.1.1 > > [Qin]: Is it real that there is no interoperability consideration since > Interoperability with Previous Implementations is discussed in the section 8 > of this document? > > Roni: Go od, add of this RFC I added the "Interoperability Consideration" which refers to sec.8. > 4. Section 3.2.1 > > [Qin]: I believe it is not appropriate to spell this note out when this > document is published but you may put > it as errata or in the section 7. > > Roni: good point. Maybe discuss it in section 8, since this may be an > interoperability issue This discussion moved to sec.8. > Also not that the syntax " < > span lan > 0pt;font-family:"Courier New"'>a=fmtp:<payload type> encode=<DV-video > encoding> audio=<audio > > bundled>" > > Does not have ";" before the audio while the examples have, I think that ";" > should separate between the parameters. I fixed the syntax. > 5. Section 3.2.1 > > Roni: I do not see this as a major issue. It can stay from my point of view. > > 6. Section 3.2.1 > > [Qin]: s/ a format specifc parameter/ a format of specific parameter > > Roni: the current text is OK > > 7. Section 3.2.1 > > [Qin] s/one of the following/one of the following value. > One question is: > How do you distinguish between required parameter or optional parameter in > the a=fmtp line? > > 8. Section 3.2.2 > > [Qin]: When you are talking about encode, you are using "encoding > type","DV-video encoding", "type of DV format" in the section 3.2, > and using "encode type" in section 3.2.2, should they be the same thing? why > not use the same terminology for consistency? > > Roni: The only issue I see is in > > "The required parameter <DV-video encoding>" which should be "The required > parameter "encode"" I changed it. > 9. Section 3.2.2" > > [Qin]: Does it worth a exmaple to expain how SDP Grouping Framework can be > used to correlate audio with video data in the section 3.3.1? > > Roni: I think that there is example in RFC 5888, so I will leave it to the > authors. I mentioned about this example. > 10. Section 3.3.1 > > [Qin]: What do you mean "when this is done"? It is not clear to me from the > context. > > Roni: to me it looks like if what is said in the previous sentence. I changed it as more clearly. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf