ietf
[Top] [All Lists]

Re: [payload] [Payload] Last Call: <draft-ietf-payload-rfc3189bis-02.txt> (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard

2011-10-20 02:55:25
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [payload] [Payload] Last Call: <draft-ietf-payload-rfc3189bis-02.txt> (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard, Kazuhiro Mishima <=