Re: [AVT] Comments on draft-ietf-text-red-00.txt

Magnus,

> >>1. Section 3: rate parameter: I think the "may" in the last sentence
> >>should be a normative one.
> >>
> >>
> >
> >What do you mean by "normative"?
> >
>
> You should use normative language, in other words the MAY normative word
> that you use through reference to RFC 2119.

Got it.. it's now MAY.  As a general question, why would capitalization
suggest a different meaning?

> >>5. Section 4, the last bullet for the "pt" list. This is under
> >>specified, the following problems exist:
> >>-  The removal or not of <"> quoting etc. is not defined.
> >>
> >>
> >
> >Are you suggesting that people would not necessarily know if the quotes
> >are
> >part of the syntax or not?
> >
> >
> You are stripping the outer quotation marks, are you leaving the inner
> in place, in there converted form, or do you change to standard quotation?

Well, this is a good question.  Clearly, I know what the end result is to
be, but how should this be written?  The text I am using was borrowed from
RFC 3555, which uses the same notation.  Please suggest specific changes to
clarify this.

> >>- How to handle any "dynamic-payload-type "=" content-type" string is
> >>also not explained.
> >>
> >>
> >
> >I do not understand your concern.  Can you explain further?
> >
> >
>
> When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the
> pt=content-type structure at all. As the information is available in the
> SDP as defined PT. Therefore you only need to reference these PTs. So
> when having SDP should you in fact remove all of these pt=content-type
> declarations and only use PTs in the list?
>
> I would also like to point out that the this declaration of
> "dynamic-payload-type "=" content-type" is not sufficiently clear. For
> RTP payload formats using parameters to configure this, this string is
> insufficient unless the parameter list can be included in the
> content-type part.

Ah, I understand.  As I mentioned above, this follows the example in RFC
3555, which also does not go into discussion on this (as far as I know).  I
assume the reason for that was simply that the entire focus was on SDP,
anyway, with little focus on MIME, really.

In any case, I can add text in this regard, but I need some guidance as to
what we should have inserted to make this clearer.

> >>7. Section 5: A proposal for how to handle the security problem is
> >>always good. Proposal: "To prevent modification of the primary,
> >>secondary or header information, payload integrity protection over at
> >>least the complete RTP packet is recommend, for example using SRTP
> >>
> >>
> >[]."
> >
> >I agree with the added text, but concerned about referencing SRTP
> >explicitly.  Will the RFC be published before this document?  I do not
> >want
> >to hold up progress due to a reference.  Would be be OK to leave off
> >"for
> >example using SRTP"?
> >
>
> The SRTP is in the RFC editors queue, so yes, it will be available
> before this document. Put SRTP into the informative reference list and
> write an RFC editors note that request that he replace the draft
> reference with the RFC number when it becomes available.

OK.. no problem.

Paul

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt