Subject: [AVT] Reminder: WG Last Call: draft-ietf-avt-text-red-02.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Apr 2004 15:18:29 +0200

Hi,

Formally the WG last call ends today, however as none has sent any 
review, it will not be advance from WG last call state. So please review 
the document and send your indication of having done so, and also 
provide any comments, editorial or technically.

I would also like to point out to all participants on this mailing list 
(around 1000) that: Unless one is ready to perform a little bit of 
review for others, one should not expect that for ones own documents. 
Spending a little bit time on others document, can be beneficial in many 
ways. Authors gain a lot in seeing more examples on how to write documents.

Cheers

Magnus

Magnus Westerlund wrote:

> This is to announce a working group last call on the "Registration of 
> the text/red MIME Sub-Type" (draft-ietf-avt-text-red-02.txt).
> http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-02.txt
> 
> Please send any final comments on this draft to the mailing list by
> Thursday the 8th April 2004.
> At that time, we will consider if it is appropriate to request
> publication of this draft as a proposed standard RFC.
> 
> Note that this draft will not be advanced until we receive at least one
> valid review from someone not directly involved with production of the
> draft (i.e., not an author or a major contributor).
> 
-- 

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]

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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sun, 11 Apr 2004 07:46:37 +0200

Magnus,
There has been a good discussion in the avt list about the use of the
a=fmtp parameter for text-red. The discussion has been linked to the
parallell work with real time text transmission in RFC2793bis, but is valid
for text-red and should possibly influence the text-red draft slightly.

Here are my review of text-red-02 including the result of the discussion on
a=fmtp:

1. In section 4, there is this sentence:
"Any dynamic payload type in the list MUST NOT include its content-
   type only the payload type number."
The "type only" comes out a bit strange. I suggest rewording to what you
shall do:
"Any dynamic payload type in the list MUST be represented by its payload
type number and not by its content-type."

2. The offer-answer aspects of the a=fmtp parameter
In a separate mail in the avt thread discussing a=fmtp for RFC2198, I enter
offer-answer considerations for the a=fmtp parameter and suggest that this
sentence is included in the sdp mapping section of text-red spec:

"In an offer/answer situation, the fmtp parameter in the answer MAY
describe a different number of redundant levels than in the offer. The
session SHOULD use the highest number of redundant levels described."

Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Magnus
> Westerlund
> Sent: Thursday, April 08, 2004 3:18 PM
> To: Magnus Westerlund
> Cc: IETF AVT WG
> Subject: [AVT] Reminder: WG Last Call: draft-ietf-avt-text-red-02.txt
>
>
> Hi,
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 26 Apr 2004 09:48:02 +0100

> type number and not by its content-type."

okay

> session SHOULD use the highest number of redundant levels described."

I don't think this is appropriate due to the problem of asymmetric loss 
we've previously discussed. I would suggest that the "text/red" 
registration remain silent about this issue, and that we consider 
offer/answer considerations for redundant audio when RFC 2198 is 
revised for Draft Standard. This will ensure that we have consistent 
specifications for all uses of the format.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Mon, 26 Apr 2004 14:57:49 +0200

I think it is OK to not detail the offer/answer aspects of the length of
the pt parameter list for expressing desired redundancy level.

One more thing I weant to be sure of, is that there is a good description
of the exact mapping of the position in the pt list to the level of
redundancy.

I still doubt that this is how RFC2198 is used in reality. I have even got
the impression that RFC2198 is used to get a chance to express alternative
or even complementary codings of the same sample sent in the same packet.
Is that how RFC2833 is transmitted? As alternate codings in the same packet
as the original audio coded sample is?

If that has become a habit, the use of fmtp for rfc 2198 audio should
reflect that, and there would be no reason to do anything else for
text-red.

Please note that there is an  draft-ietf-avt-text-red-03.txt out there at
http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-03.txt

Regards

Gunnar

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Monday, April 26, 2004 10:48 AM
> To: Gunnar Hellstrom
> Cc: IETF AVT WG; Magnus Westerlund
> Subject: Re: [AVT] Reminder: WG Last Call:
> draft-ietf-avt-text-red-02.txt
>
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 28 Apr 2004 17:45:54 +0100

There seem to be enough users of RFC 2198 that we should consider 
working on an update, including all the MIME registrations and 
Offer/Answer Considerations. We could publish 
draft-ietf-avt-text-red-??.txt in a form that matches the existing MIME 
type registration for audio/red, and handle all clarifications when we 
revise RFC 2198. This would still allow us to meet the ITU's deadline 
for RFC 2793bis, then give us chance to properly clarify the use of RFC 
2198 based on implementation experience.

Do people think this is a good idea? want to volunteer to do the work?

Colin

-- 
Colin Perkins
http://csperkins.org/