Subject: [AVT] RE: Comments on draft-ietf-avt-rtp-vc1-01

From: "Anders Klemets" <[email-masked]>
Date: Mon, 7 Nov 2005 19:15:01 -0800

Magnus and Colin,

Thanks for taking the time to review draft-ietf-avt-rtp-vc1-01.  I think
I can address all of your comments in the next version (-02).

As for adding additional SDP parameters to support the SIP
"offer/answer" feature, I wonder if it is a requirement these days that
all new RTP payload formats should come with built-in support for this
functionality?  Or is this something that could be defined at a later
date, by the appropriate SIP working group?

If we were to omit "offer/answer" from this spec, does it need to
mention that IANA maintains a registry of MIME/SDP parameters?  Colin's
comment seemed to suggest that it is necessary to mention this.  The
spec already mentions that IANA should register "video/vc1".  Doesn't
that imply that IANA will also register any additional MIME parameters
that the IETF may want to define in the future?

As for the numbering of the headings and the title headings being split
into separate lines, I don't know why that happened. The document that I
e-mailed to [email-masked] does not have that problem.  Would
they have edited the document for some reason?

Thanks,

Anders 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 08 Nov 2005 04:39:48 +0100

Hi Anders,

See inline.

> date, by the appropriate SIP working group?

No, you don't usually add extra parameters for offer/answer. The 
parameters I was discussing was what is needed to support any 
bi-directional usage basically.

What we do require is to describe how the payload format parameters will 
be used in offer/answer (RFC 3264). And no, we don't offload this work 
to any SIP groups and it is needed for all formats.

If we wouldn't define offer/answer considerations you end up with 
discussions like the one around RFC 3016 and how to interpret the 
parameters. It is also very good to think how different parameters 
actually will be used. That way they will be defined in a way that is 
more useful.

> that the IETF may want to define in the future?

The question Colin made was if any of the payload format parameters has 
a specific value space that could be extended in the future. Examples of 
this is the color-space and sampling used in RFC 4175.

> they have edited the document for some reason?

No, not likely. It might be some character encoding issues. If you used 
Word to produce the draft it is common to end up with characters that 
aren't in the 7-bit ascii set.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]