[AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: Storage format

sassan.ahmadi@nokia.com Fri, 03 September 2004 18:01 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02300 for <avt-archive@ietf.org>; Fri, 3 Sep 2004 14:01:35 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3IQ8-0005Ra-IY for avt-archive@ietf.org; Fri, 03 Sep 2004 14:04:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IDI-00071e-Sg; Fri, 03 Sep 2004 13:51:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3IBQ-0006iN-6a for avt@megatron.ietf.org; Fri, 03 Sep 2004 13:49:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01387 for <avt@ietf.org>; Fri, 3 Sep 2004 13:49:05 -0400 (EDT)
From: sassan.ahmadi@nokia.com
Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3I0P-0004e2-Qo for avt@ietf.org; Fri, 03 Sep 2004 13:37:47 -0400
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i83HYqj23801; Fri, 3 Sep 2004 20:34:52 +0300 (EET DST)
X-Scanned: Fri, 3 Sep 2004 20:34:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i83HYYhj015336; Fri, 3 Sep 2004 20:34:34 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00b9mwZb; Fri, 03 Sep 2004 20:34:30 EEST
Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i83HYTS05480; Fri, 3 Sep 2004 20:34:29 +0300 (EET DST)
Received: from sdebe002.NOE.Nokia.com ([172.19.201.138]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 12:34:05 -0500
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 03 Sep 2004 10:34:04 -0700
Message-ID: <0B08EA1BF5F6304992CDC985EE02209E02A74359@sdebe002.americas.nokia.com>
Thread-Topic: <draft-ietf-avt-rtp-vmr-wb-03.txt>: Storage format
Thread-Index: AcSRlH35TZlpLzvSSqujVRIkC0syPQARNwUA
To: magnus.westerlund@ericsson.com
X-OriginalArrivalTime: 03 Sep 2004 17:34:05.0078 (UTC) FILETIME=[35918B60:01C491DC]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org, csp@csperkins.org
Subject: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: Storage format
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable

Magnus,

> > While I added the necessary notes to Section 7 (storage format), I
> > decided not to remove this section for the following reasons:
> > 
> > - This section and Section 8.5 of the 3GPP2 VMR-WB specification are
> > fully consistent.
> > 
> > - I was advised by some 3GPP2 colleagues that the I-D is 
> the best place
> > to define the storage format.
> > 
> 
> Do, you or do you not have a full specification in the 3GPP2 
> specifications of the storage format?

Section 8.5 of VMR-WB spec describes the MIME/file storage format. The reason I described the storage format in VMR-WB spec was that at that time VMR-WB RFC was not published and could not be referenced. 

We believe that the best place to describe the storage format is the VMR-WB RFC.

Currently both VMR-WB I-D, software, and spec are fully consistent in the definition of the storage format.

If you agree, let's keep the storage format in VMR-WB RFC and I will remove the storage format description in Release A of the VMR-WB specification (that includes VMR-WB extension) which is being drafted and which is scheduled for publication as 3GPP2 C.S0052-A v1.0 in April 2005. Because by that time, the VMR-WB RFC is hopefully published and can be referenced.

That way, we do not have to be worried about updating two specifications, should a revision is necessary.

Regards

-Sassan Ahmadi

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