Re: [MMUSIC] MMUSIC stage and studio requirements I-D ...

lazzaro <lazzaro@eecs.berkeley.edu> Fri, 08 July 2005 23:41 UTC

Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17373 for <mmusic-archive@ietf.org>; Fri, 8 Jul 2005 19:41:41 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr2v2-0002jb-ON for mmusic-archive@ietf.org; Fri, 08 Jul 2005 20:10:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2S1-00020V-DI; Fri, 08 Jul 2005 19:40:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2Ry-0001s1-2h; Fri, 08 Jul 2005 19:40:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17212; Fri, 8 Jul 2005 19:40:03 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr2tQ-0002fZ-25; Fri, 08 Jul 2005 20:08:30 -0400
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id j68NdvBn015189 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 8 Jul 2005 16:39:58 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <0D2BA9C7-09B9-4177-A45B-0D2ABD1FB81E@eecs.berkeley.edu>
Content-Transfer-Encoding: 7bit
From: lazzaro <lazzaro@eecs.berkeley.edu>
Subject: Re: [MMUSIC] MMUSIC stage and studio requirements I-D ...
Date: Fri, 08 Jul 2005 16:40:32 -0700
To: mmusic@ietf.org, avt@ietf.org
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit

Shigeru Aoki" <shig at center.jfn.co.jp> writes:
> First of all, You should not include your matter into the AES-X074  
> since it has different intention from yours. Your requirements  
> draft should be proposed to the WG for the discussion in the WG. if  
> you would like to work for professional audio, you'd better propose  
> to the AES too.

I think it is premature.

MMUSIC first has to decide if it has interest in
the topic, and in particular, if it is open to
considering extensions to the transport protocols
over which it owns change control (RTSP and SDP)
to support requirements that this I-D may suggest.

I am expecting significant MMUSIC opposition to the
concept, given the changes some of the proposed
requirements would mandate (MMUSIC folk: read
the I-D for details).

However, If there is MMUSIC interest, then I think
its time to contact AES and the MMA and let
them know of the new IETF work starting.

It takes exceptional circumstances for the
IETF to open a standardization collaboration
with another body. A recent example is 3GPP:

http://www.3gpp.org/tb/Other/IETF.htm

Instead, the way the IETF would prefer to work
in this case is for individuals that participate in
the AES standards process to participate in
MMUSIC, and lend their expertise to the effort
in that way.  This is fair because the MMA and
SMPTE could also participate in the same way,
as MIDI and SMPTE video streams could also
be managed by a stage and studio RTSP.  Whereas
a 4-way standards collaboration would be hopeless.

And so, our initial AES contact would be an
invitation to join in our effort, with the hopes
that the AES would adopt our final documents
as standards without change.  If there was not
AES interest in working this way, my guess the
IETF would decide to drop the effort, and I would
hand off responsibility for RTP MIDI session
management protocols for stage and studio work
(which is my personal reason for proposing this
I-D) to the MMA and end my leadership role.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic