From exim@www1.ietf.org Wed May 5 06:23:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04923 for ; Wed, 5 May 2004 06:23:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJRO-00027M-Id for mmusic-archive@odin.ietf.org; Wed, 05 May 2004 06:15:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45AFoDQ008140 for mmusic-archive@odin.ietf.org; Wed, 5 May 2004 06:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJP9-0000yb-Fs for mmusic-web-archive@optimus.ietf.org; Wed, 05 May 2004 06:13:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04463 for ; Wed, 5 May 2004 06:13:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLJP5-0004f4-OK for mmusic-web-archive@ietf.org; Wed, 05 May 2004 06:13:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLJO7-0004ST-00 for mmusic-web-archive@ietf.org; Wed, 05 May 2004 06:12:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLJNf-0004Gi-00 for mmusic-web-archive@ietf.org; Wed, 05 May 2004 06:11:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJDB-000516-7N; Wed, 05 May 2004 06:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJBk-0004N8-HK for mmusic@optimus.ietf.org; Wed, 05 May 2004 05:59:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03462 for ; Wed, 5 May 2004 05:59:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLJBg-0001Zl-QY for mmusic@ietf.org; Wed, 05 May 2004 05:59:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLJ7c-0000uW-00 for mmusic@ietf.org; Wed, 05 May 2004 05:55:25 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLJ5b-0000KC-02 for mmusic@ietf.org; Wed, 05 May 2004 05:53:19 -0400 Received: from smtp6.clb.oleane.net ([213.56.31.26]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLIsk-0007Ct-QD for mmusic@ietf.org; Wed, 05 May 2004 05:40:02 -0400 Received: from Pavillonquatre ([194.206.151.59]) by smtp6.clb.oleane.net with ESMTP id i459dTGr008289 for ; Wed, 5 May 2004 11:39:29 +0200 Message-Id: <200405050939.i459dTGr008289@smtp6.clb.oleane.net> From: "Peter Lewis" To: Date: Wed, 5 May 2004 11:39:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C43295.9FEC83D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQyhNvny4jYagYvRr6BTs3sY0o4VA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: [MMUSIC] TVoDSL 2005: Broadcasting TV content over ADSL Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C43295.9FEC83D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit TVoDSL 2005: Broadcasting TV content over ADSL Home networks, middleware, access networks and compression tools: all the TVoDSL technical issues will be addressed in detail by the major manufacturing, economic and regulatory players in this promising new market at the TVoDSL Conference, to take place in Paris on January 25 to 28, 2005. The organizers expect more than 600 participants and 40 exhibitors at the Triple Play Showcase. The call for proposals dead line has been extended to May 28 Get all details at: http://www.upperside.fr/tvodsl2005/tvodsl2005cfp ------=_NextPart_000_0028_01C43295.9FEC83D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TVoDSL 2005: Broadcasting TV content over ADSL


Home networks, middleware, access networks and compression tools: all = the TVoDSL technical issues will be addressed in detail by the major manufacturing, economic and regulatory players in this = promising new market at the TVoDSL Conference, to take place in Paris on January 25 to 28, 2005. =

The organizers expect more than 600 = participants and 40 exhibitors at the Triple Play Showcase.

 

The call for proposals dead line has been = extended to May 28

 

Get all details = at:

http://www.upperside.fr/tvodsl2005/tvodsl2005cfp<= /span>

 

 

 

------=_NextPart_000_0028_01C43295.9FEC83D0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed May 5 23:38:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00505 for ; Wed, 5 May 2004 23:38:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLZeM-0005BZ-PR for mmusic-archive@odin.ietf.org; Wed, 05 May 2004 23:34:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i463YIwO019933 for mmusic-archive@odin.ietf.org; Wed, 5 May 2004 23:34:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLZdK-0004bT-3i for mmusic-web-archive@optimus.ietf.org; Wed, 05 May 2004 23:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00326 for ; Wed, 5 May 2004 23:33:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLZdH-00042b-OP for mmusic-web-archive@ietf.org; Wed, 05 May 2004 23:33:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLZcI-0003hB-00 for mmusic-web-archive@ietf.org; Wed, 05 May 2004 23:32:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLZbF-0003D1-00 for mmusic-web-archive@ietf.org; Wed, 05 May 2004 23:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLZVP-0002RK-TJ; Wed, 05 May 2004 23:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLZUe-00022x-2I for mmusic@optimus.ietf.org; Wed, 05 May 2004 23:24:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29864 for ; Wed, 5 May 2004 23:24:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLZUb-00012U-V1 for mmusic@ietf.org; Wed, 05 May 2004 23:24:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLZTW-0000ON-00 for mmusic@ietf.org; Wed, 05 May 2004 23:23:07 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1BLZSN-0007lk-00 for mmusic@ietf.org; Wed, 05 May 2004 23:21:55 -0400 Date: Wed, 05 May 2004 20:05:33 -0700 From: rtspspec-bugs-request@lists.sourceforge.net Message-ID: To: mmusic@ietf.org Reply-to: mmusic@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_goobox-18196-1083813669-0001-2" Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #124 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, NO_REAL_NAME autolearn=no version=2.60 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_goobox-18196-1083813669-0001-2 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Comment: The following content can be customized provided that: Comment: 1) These MIME headers are preserved (you may change the charset Comment: or drop format=flowed). Comment: 2) This content is manually quoted-printable encoded, it MUST NOT Comment: contain 8-bit text. Comment: 'goobox' below is replaced by server name. Content-Transfer-Encoding: quoted-printable CORRUPTED MESSAGE This is the Courier Mail Server 0.36.1 on goobox. I received the following message for delivery to your address. Unfortunately, this message apparently fails to comply with Internet mail formatting protocols, and I can only deliver mail which has been properly formatted in accordance with Internet standards. Instead of rejecting that message as undeliverable, I saved it as the following attachment, which you can open with any editor or word processor. Please notify the original sender that their message was not properly formatted by their mail software. The specific mail protocol error is as follows: ----------------------------------------------------------------------------- The following message contains 8-bit content, but does not have the required MIME headers for 8-bit data transport. See for more information. ----------------------------------------------------------------------------- --=_goobox-18196-1083813669-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="message.txt" X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.36.1 Content-Transfer-Encoding: quoted-printable Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 05 May 2004 20:21:08 -0700 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list1.sourceforge.net ([::ffff:66.35.250.206]) (TL= S: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by scarface.real.com with esmtp; We= d, 05 May 2004 20:17:07 -0700 Received: from localhost ([127.0.0.1] helo=3Dprojects.sourceforge.net) b= y sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1BLZNp-0005Ib-1= q for robla@real.com; Wed, 05 May 2004 20:17:13 -0700 Date: Wed, 05 May 2004 20:05:33 -0700 From: rtspspec-bugs-request@lists.sourceforge.net Subject: Rtspspec-bugs digest, Vol 1 #124 - 1 msg X-Mailer: Mailman v2.0.9-sf.net MIME-version: 1.0 Content-type: text/plain Old-To: rtspspec-bugs@lists.sourceforge.net Sender: rtspspec-bugs-admin@lists.sourceforge.net Errors-To: rtspspec-bugs-admin@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-ID: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on scarface.real.= com X-Spam-Status: No, hits=3D-4.5 required=3D5.0 tests=3DAWL,BAYES_00,NO_RE= AL_NAME autolearn=3Dno version=3D2.63 X-Spam-Level: To: mmusic@ietf.org Reply-to: mmusic@ietf.org This is an automatic digest of bugs submitted and changed on the RTSP bu= g tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rts= pspec-bugs digest" Today's Topics: 1. =3D?GB2312?B?u9i4tKOsyOe6zsq2sfDN+MLn1anGraOh?=3D (=3D?GB2312?B?zf= jC57ncwO3W0NDE?=3D) --__--__-- Message: 1 From: =3D?GB2312?B?zfjC57ncwO3W0NDE?=3D To: rtspspec-bugs@lists.sourceforge.net Reply-To: chn88@tom.com Date: Thu, 6 May 2004 00:40:55 +0800 Subject: [rtspspec-bugs] =3D?GB2312?B?u9i4tKOsyOe6zsq2sfDN+MLn1anGraOh?=3D =C5=F3=D3=D1=A3=BA =A1=A1=A1=A1=C4=FA=BA=C3=A3=A1 =A1=A1=A1=A1=D7=EE=BD=FC=D3=D0=B2=BB=C9=D9=CD=F8=D3=D1=B7=B4=D3=B3=D2=AA= =C7=F3=CE=D2=C3=C7=CC=E1=B9=A9=D2=BB=D0=A9=C8=E7=BA=CE=CA=B6=B1=F0=CD=F8= =C2=E7=D5=A9=C6=AD=B5=C4=D0=C5=CF=A2=A3=AC=D2=F2=B4=CB=CE=D2=C3=C7=D7=DC= =BD=E1=C1=CB=D2=D4=CF=C2=BC=B8=B5=E3=D2=D4=B9=A9=B2=CE=BF=BC=A3=A1 =A1=A1=A1=A1 1=A1=A2=B9=AB=CB=BE=C3=FB=B3=C6=B2=E9=D1=AF=A3=AC=CF=C8=CD=A8=B9=FD=C8=AB= =B9=FA=B9=A4=C9=CC=CD=F8=D6=B1=BD=D3=B2=E9=D1=AF=C6=F3=D2=B5=B5=C4=D3=AA= =D2=B5=D6=B4=D5=D5=A3=AC=BA=CB=CA=B5=B8=C3=B9=AB=CB=BE=CA=C7=B7=F1=D5=E6= =CA=B5=B4=E6=D4=DA=A3=BB 2=A1=A2=B9=AB=CB=BE=D5=CB=BA=C5=B2=E9=D1=AF=A3=AC=D6=B1=BD=D3=CF=F2=D2=F8= =D0=D0=D7=C9=D1=AF=D5=CB=BA=C5=CA=C7=B7=F1=CE=AA=B6=D4=B9=AB=D5=CB=BA=C5= =A3=BB 3=A1=A2=B9=AB=CB=BE=B5=E7=BB=B0=B2=E9=D1=AF=A3=AC=CD=A8=B9=FD=B8=F7=B5=D8= 114=B2=E9=BA=C5=CC=A8=D6=B1=BD=D3=B2=E9=D1=AF=A3=AC=D5=FD=B9=E6=C6=F3=D2= =B5=CD=F8=D5=BE=C9=CF=D2=BB=B0=E3=B2=BB=BB=E1=C1=F4=CB=BD=C8=CB=B5=E7=BB= =B0=A3=BB 4=A1=A2=B9=AB=CB=BE=C1=AA=CF=B5=B5=D8=D6=B7=A3=AC=BF=C9=D2=D4=CD=A8=B9=FD= =B5=B1=B5=D8=B5=C4=B5=E7=BB=B0=BA=C5=C2=F0=B2=E9=D1=AF=CA=C7=B7=F1=CA=F4= =CA=B5=A3=BB 5=A1=A2=CD=F8=C2=E7=CB=D1=CB=F7=B2=E9=D1=AF=A3=AC=CD=A8=B9=FD=D4=DA http= ://www.google.com =BB=F2 http://www.baidu.com =C9=CF=CB=D1=CB=F7=C1=CB=BD= =E2=B8=FC=B6=E0=D0=C5=CF=A2! =C1=ED=CD=E2=CE=D2=C3=C7=BB=B9=CA=D5=BC=AF=C1=CB=B2=BF=B7=D6=B5=E4=D0= =CD=D5=A9=C6=AD=B0=B8=C0=FD=A3=AC=C7=EB=B5=E3=BB=F7=A3=BA http://www.88d= ns.com/315.htm =B2=E9=BF=B4=A3=A1 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 =A1=A1=A1= =A1=A1=A1=A1=A1=B6=AB=C4=CF=C6=F3=D2=B5=B7=FE=CE=F1=A3=A8=CD=F8=C2=E7=B9= =DC=C0=ED=D6=D0=D0=C4=A3=A9 End of Rtspspec-bugs Digest --=_goobox-18196-1083813669-0001-2-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 05:48:50 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01613 for ; Thu, 6 May 2004 05:48:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfS6-0004VI-BG for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 05:46:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i469k2rI017275 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 05:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfJk-0001Ie-Vc for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 05:37:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01086 for ; Thu, 6 May 2004 05:37:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfJh-0006xP-J3 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 05:37:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfHj-0006Pi-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 05:35:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLfFk-0005ZJ-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 05:33:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfAh-0005Up-FK; Thu, 06 May 2004 05:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLf5L-0003gc-2w for mmusic@optimus.ietf.org; Thu, 06 May 2004 05:22:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00162 for ; Thu, 6 May 2004 05:22:27 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLf5H-0001Xf-PZ for mmusic@ietf.org; Thu, 06 May 2004 05:22:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLf4G-0000uO-00 for mmusic@ietf.org; Thu, 06 May 2004 05:21:25 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLf1z-0007iu-00 for mmusic@ietf.org; Thu, 06 May 2004 05:19:03 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i469IcB01115; Thu, 6 May 2004 12:18:38 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 12:18:30 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i469IUfp020020; Thu, 6 May 2004 12:18:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00AvytFZ; Thu, 06 May 2004 12:18:28 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i469ISH09838; Thu, 6 May 2004 12:18:28 +0300 (EET DST) Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 May 2004 12:18:28 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 May 2004 12:18:27 +0300 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: Thu, 6 May 2004 12:18:27 +0300 Message-ID: Thread-Topic: [MMUSIC] And one more SDP-quiz question on protocol IDs Thread-Index: AcQtvI3qO25XPhzOT1ezTNgJsc42+gFjFTtA To: , , Cc: , X-OriginalArrivalTime: 06 May 2004 09:18:27.0924 (UTC) FILETIME=[1745F140:01C4334B] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] sdp-new unregistered media types Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Mark, Van, Colin, Is Magnus's suggestion, to 'depreciate' "data" and "control" from SDP = until they are IANA registered, feasible or likely? (My interest lies in whether or not to consider using "data"). Cheers, Rod. > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, April 29, 2004 10:33 AM > To: Walsh Rod (Nokia-NRC/Tampere) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs > To avoid further confusion I am of the opinion that=20 > draft-ietf-sdp-new=20 > should be updated to move all unregistered media types into a=20 > note like: >=20 > Note: RFC 2326 mentions the media types "data" and "control",=20 > these are=20 > unregistered media types and should not be used. If these media types=20 > are deemed suitable in the future, they should be registered in=20 > accordance with section 9.2.1. >=20 > Cheers > Magnus _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 05:49:20 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01657 for ; Thu, 6 May 2004 05:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfSp-0004fK-Qu for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 05:46:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i469klnC017916 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 05:46:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfKv-0001vO-W8 for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 05:38:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01206 for ; Thu, 6 May 2004 05:38:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfKs-0007iX-JD for mmusic-web-archive@ietf.org; Thu, 06 May 2004 05:38:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfK0-0007Ft-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 05:37:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLfIN-0006So-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 05:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfEc-0007AH-LX; Thu, 06 May 2004 05:32:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfAE-0005EX-NB for mmusic@optimus.ietf.org; Thu, 06 May 2004 05:27:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00339 for ; Thu, 6 May 2004 05:27:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfAB-0003Ry-BN for mmusic@ietf.org; Thu, 06 May 2004 05:27:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLf9F-00035Z-00 for mmusic@ietf.org; Thu, 06 May 2004 05:26:33 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BLf8n-0002jH-00 for mmusic@ietf.org; Thu, 06 May 2004 05:26:05 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63401 helo=[192.168.0.3]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BLf8G-00033h-00; Thu, 06 May 2004 10:25:32 +0100 From: Colin Perkins Organization: http://csperkins.org To: Date: Thu, 6 May 2004 10:25:32 +0100 User-Agent: KMail/1.6.2 Cc: , , , References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405061025.32203.csp@csperkins.org> Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: sdp-new unregistered media types Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 06 May 2004 10:18, Rod.Walsh@nokia.com wrote: > Is Magnus's suggestion, to 'depreciate' "data" and "control" from SDP > until they are IANA registered, feasible or likely? I submitted -16 yesterday, without making that change. Unless there is strong consensus from the group to do so, I wish to avoid changes that are not backwards compatible. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 06:13:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02901 for ; Thu, 6 May 2004 06:13:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfpK-0006AN-F2 for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 06:10:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46AA253023699 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 06:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfiR-0002ym-VB for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 06:02:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02490 for ; Thu, 6 May 2004 06:02:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfiO-0001cH-B9 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 06:02:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfhE-0001DI-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 06:01:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLfgc-0000pV-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 06:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfbl-0000Rg-Tv; Thu, 06 May 2004 05:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfTi-00055S-DD for mmusic@optimus.ietf.org; Thu, 06 May 2004 05:47:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01464 for ; Thu, 6 May 2004 05:47:38 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfTe-0003JL-SX for mmusic@ietf.org; Thu, 06 May 2004 05:47:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfSe-0002u1-00 for mmusic@ietf.org; Thu, 06 May 2004 05:46:37 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BLfRi-0002X5-00; Thu, 06 May 2004 05:45:38 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i469jTH01803; Thu, 6 May 2004 12:45:29 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 12:44:26 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i469iQAY011849; Thu, 6 May 2004 12:44:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00fpwQ2h; Thu, 06 May 2004 12:44:24 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i469iNH16127; Thu, 6 May 2004 12:44:23 +0300 (EET DST) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 May 2004 12:44:22 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 May 2004 12:44:22 +0300 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: Thu, 6 May 2004 12:44:20 +0300 Message-ID: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-06.txt Thread-Index: AcQiYWWlGJ3m4fX3Rbazk0G2F+ejsQK4ukEQAX9Et/A= To: , Cc: , , , , , , , X-OriginalArrivalTime: 06 May 2004 09:44:22.0013 (UTC) FILETIME=[B5951AD0:01C4334E] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] SDP Session Description for FLUTE Sessions Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable To summarise the discussion so far: Media descriptions (a "m=3D" line and a "a=3D" line) can be used to = specify the group/destination address & port of FLUTE session channels. We need a new protocol id for FLUTE. It will be either FLUTE/UDP or = UDP/FLUTE and the difference seems trivial to implementations. We need to understand how media types work with FLUTE. It is possible to = allow any media types (of SDP and IANA) as long at the FLUTE transported = files adhere to this. It is also possible to recommend that = "application" media is used. The can be used to specify the reciever application type (e.g. = "wb" for whiteboard). A "null" (i.e. dummy) fmt value could be used to = say 'the application has to work out the file MIME types some other = way', which is the expected use in many cases. FLUTE's FDT is one way to = do this. An out-of-flute-session-band method would also be desirable to = allow a multitude of different content-specialised FLUTE receiver = applications on a host, but it seems that this is out of SDP 'for FLUTE' = scope. I've seen "0" used for a fmt "null" value - is that common = practice? So we might be looking at... m=3Dapplication 32416 FLUTE/UDP 0 a=3D ...in a typical case. Note, "m=3Ddata..." is also on the cards for the = typical case. Personally I see: m=3Ddata 32416 FLUTE/UDP 0 for generic FLUTE receivers which are distinct from the user rendering = interface... m=3Dapplication 32416 FLUTE/UDP 0 for generic FLUTE receivers which include the user rendering interface, = so "integtrated multimedia applciations"... m=3Dapplication 32416 FLUTE/UDP pdf m=3Dvideo 32416 FLUTE/UDP mpeg for homogeneous single content-specific FLUTE sessions Unfortunately, except in extremely tightly controlled closed systems, a = FLUTE sender would not require the first two to be differentiated (it's = upto the reciever to deal with mixed content), so both "data" or = "application + fmt=3Dnull" will mean exactly the same thing. (Note "FLUTE/UDP", "data" and fmt values "0" are not currently IANA = registered). Since making channels content specific would interact with the LCT = congestion control building block used, it's probably wise to strongly = recommend that this is only done by a congestion control building block = and not allow SDP to interfere with that. Thus, I propose that the same = media type and fmt value is used for all "m=3D" lines with the FLUTE = protocol id in a singe SDP description. It doesn't harm to have the links in one handly place: FLUTE: http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-07.txt SDP: http://www.ietf.org/rfc/rfc2327.txt SDP with IPv6: http://www.ietf.org/rfc/rfc3266.txt SDP-NEW: = http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-15.txt IANA/MIME Media Types: = http://www.iana.org/assignments/media-types/index.html Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 07:04:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05928 for ; Thu, 6 May 2004 07:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgeE-0002NF-8a for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 07:02:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46B2cg4009126 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 07:02:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgbP-000118-DX for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 06:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05530 for ; Thu, 6 May 2004 06:59:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLgbL-0000mJ-73 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 06:59:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgaK-0000NG-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 06:58:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLgZW-0007nD-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 06:57:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgP7-0005JC-JS; Thu, 06 May 2004 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfUn-0005mR-CM for mmusic@optimus.ietf.org; Thu, 06 May 2004 05:48:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01611 for ; Thu, 6 May 2004 05:48:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfUj-0003kd-RG for mmusic@ietf.org; Thu, 06 May 2004 05:48:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfTy-0003ML-00 for mmusic@ietf.org; Thu, 06 May 2004 05:47:58 -0400 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 1BLfTG-0002wf-00 for mmusic@ietf.org; Thu, 06 May 2004 05:47:14 -0400 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.9p2/8.12.8) with ESMTP id i469lCxF014900; Thu, 6 May 2004 10:47:13 +0100 (BST) (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: Colin Perkins cc: "Rod.Walsh" , van , mmusic , "magnus.westerlund" In-reply-to: Your message of "Thu, 06 May 2004 10:25:32 BST." <200405061025.32203.csp@csperkins.org> Date: Thu, 06 May 2004 10:47:12 +0100 Message-ID: <14899.1083836832@aardvark.cs.ucl.ac.uk> Subject: [MMUSIC] Re: sdp-new unregistered media types Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >On Thursday 06 May 2004 10:18, Rod.Walsh@nokia.com wrote: >> Is Magnus's suggestion, to 'depreciate' "data" and "control" from SDP >> until they are IANA registered, feasible or likely? > >I submitted -16 yesterday, without making that change. Unless there is >strong consensus from the group to do so, I wish to avoid changes that are >not backwards compatible. Does anyone use "data" and "control"? The IANA considerations (at least in -15) only specify a SHOULD for these matching the top level MIME types: 9.2.1 Media types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level MIME content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing MIME top-level content types, a standards-track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of RFC 2434 [5].' So the lack of a MIME Content Type for these isn't a problem, but there should be a way to register media formats under these with IANA - I believe currently there isn't. But if there's no interoperability report for "data" and "control", they should clearly be deprecated before moving to draft standard. BTW, the first part of section 9 refers to a future registration of application/sdp, but this is already registered, so if you haven't already removed in from -16, you probably should do so. Cheers, Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 07:43:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07428 for ; Thu, 6 May 2004 07:43:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLhEL-0007Oe-V8 for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 07:40:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46BdvCb028428 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 07:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLh5M-0004HN-11 for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 07:30:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06730 for ; Thu, 6 May 2004 07:30:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLh5L-0005Nw-6a for mmusic-web-archive@ietf.org; Thu, 06 May 2004 07:30:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLh4U-0004xo-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 07:29:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLh3p-0004Zd-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 07:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgrD-0007nV-3o; Thu, 06 May 2004 07:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgLp-0003Qp-QU for mmusic@optimus.ietf.org; Thu, 06 May 2004 06:43:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04897 for ; Thu, 6 May 2004 06:43:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLgLl-0002N1-HC for mmusic@ietf.org; Thu, 06 May 2004 06:43:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgKq-0001ye-00 for mmusic@ietf.org; Thu, 06 May 2004 06:42:44 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BLgJx-0001B5-00 for mmusic@ietf.org; Thu, 06 May 2004 06:41:41 -0400 Received: from mangole ([130.209.247.112]:50308) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BLgJQ-0003VE-00; Thu, 06 May 2004 11:41:08 +0100 From: Colin Perkins Organization: http://csperkins.org To: Mark Handley Date: Thu, 6 May 2004 11:41:08 +0100 User-Agent: KMail/1.6.2 Cc: "Rod.Walsh" , van , mmusic , "magnus.westerlund" References: <14899.1083836832@aardvark.cs.ucl.ac.uk> In-Reply-To: <14899.1083836832@aardvark.cs.ucl.ac.uk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_EZhmAGu7QzIWJzj" Message-Id: <200405061141.08151.csp@csperkins.org> Subject: [MMUSIC] Re: sdp-new unregistered media types Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_RELAYING_FRAME autolearn=no version=2.60 --Boundary-00=_EZhmAGu7QzIWJzj Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit On Thursday 06 May 2004 10:47, Mark Handley wrote: > >On Thursday 06 May 2004 10:18, Rod.Walsh@nokia.com wrote: > >> Is Magnus's suggestion, to 'depreciate' "data" and "control" from SDP > >> until they are IANA registered, feasible or likely? > > > >I submitted -16 yesterday, without making that change. Unless there is > >strong consensus from the group to do so, I wish to avoid changes that > > are not backwards compatible. > > Does anyone use "data" and "control"? I thought "control" was used, not sure about data - expect for Rod's proposal for FLUTE. > The IANA considerations (at least in -15) only specify a SHOULD for > these matching the top level MIME types: > > 9.2.1 Media types ("media") > > The set of media types is intended to be small and SHOULD NOT be > extended except under rare circumstances. The same rules should > apply for media names as for top-level MIME content types, and where > possible the same name should be registered for SDP as for MIME. For > media other than existing MIME top-level content types, a > standards-track RFC MUST be produced for a new top-level content type > to be registered, and the registration MUST provide good > justification why no existing media name is appropriate (the > "Standards Action" policy of RFC 2434 [5].' > > So the lack of a MIME Content Type for these isn't a problem, but > there should be a way to register media formats under these with IANA > - I believe currently there isn't. True. The IANA considerations section is something which has received a lot of work in -16, but there is more to do. This is one of the things to add. > But if there's no interoperability report for "data" and "control", > they should clearly be deprecated before moving to draft standard. I expect SDP-new will cycle at proposed, there have been too many changes and there's no interop report. > BTW, the first part of section 9 refers to a future registration of > application/sdp, but this is already registered, so if you haven't > already removed in from -16, you probably should do so. The first part of Section 9 in -16 is the MIME registration template for application/sdp. Cheers, Colin --Boundary-00=_EZhmAGu7QzIWJzj Content-Type: text/plain; charset="iso-8859-1"; name="draft-ietf-mmusic-sdp-new-16.txt" Content-Disposition: attachment; filename="draft-ietf-mmusic-sdp-new-16.txt" Content-Transfer-Encoding: 7bit Network Working Group M. Handley Internet-Draft UCL Obsoletes: 2327, 3266 (if V. Jacobson approved) Packet Design Expires: November 2, 2004 C. Perkins University of Glasgow May 4, 2004 SDP: Session Description Protocol draft-ietf-mmusic-sdp-new-16.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 2, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. Handley, et al. Expires November 2, 2004 [Page 1] Internet-Draft SDP May 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 4.1 Media Information . . . . . . . . . . . . . . . . . . . . 5 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 4.4 Obtaining Further Information about a Session . . . . . . 6 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6 4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 9 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 11 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 11 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 11 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 12 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 14 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 15 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 16 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 17 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 18 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 19 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24 7. Communicating Conference Control Policy . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 9.1 The "application/sdp" media type . . . . . . . . . . . . . 31 9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 10.1 Normative References . . . . . . . . . . . . . . . . . . . 42 10.2 Informative References . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . 45 Handley, et al. Expires November 2, 2004 [Page 2] Internet-Draft SDP May 2004 1. Introduction [Note to RFC Editor: All references to RFC XXXX should be replaced by the RFC number of this document, when published.] When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a format for session description - it does not incorporate a transport protocol, and is intended to use different transport protocols as appropriate, including the Session Announcement Protocol [8], Session Initiation Protocol [9], Real-Time Streaming Protocol [10], electronic mail using the MIME extensions, and the Hypertext Transport Protocol. SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not intended to support negotiation of session content or media encodings: this is viewed as outside the scope of session description. 2. Glossary of Terms The following terms are used in this document, and have specific meaning within the context of this document. Conference: A multimedia conference is a set of two or more communicating users along with the software they are using to communicate. Session: A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session. Session Description: A well defined format for conveying sufficient information to discover and participate in a multimedia session. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 3. Examples of SDP Usage 3.1 Multicast Session Announcement In order to assist the advertisement of multicast multimedia Handley, et al. Expires November 2, 2004 [Page 3] Internet-Draft SDP May 2004 conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically sends packets containing a description of the session to a well known multicast group. These advertisements are received by other session directories such that potential remote participants can use the session description to start the tools required to participate in the session. One protocol commonly used to implement such a distributed directory is the Session Announcement Protocol, SAP [8]. SDP provides the recommended session description format for such session announcements. 3.2 Session Initiation The Session Initiation Protocol, SIP [9] is an application layer control protocol for creating, modifying and terminating sessions such as Internet multimedia conferences, Internet telephone calls and multimedia distribution. The SIP messages used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. These session descriptions are commonly formatted using SDP. When used with SIP, the offer/answer model [11] provides a limited framework for negotiation using SDP. 3.3 Streaming media The Real Time Streaming Protocol, RTSP [10], is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters. 3.4 Email and the World Wide Web Alternative means of conveying session descriptions include electronic mail and the World Wide Web. For both email and WWW distribution, the MIME content type "application/sdp" is used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner. Note that announcements of multicast sessions made only via email or the World Wide Web (WWW) do not have the property that the receiver of a session announcement can necessarily receive the session because the multicast sessions may be restricted in scope, and access to the WWW server or reception of email is possible outside this scope. Handley, et al. Expires November 2, 2004 [Page 4] Internet-Draft SDP May 2004 Session announcements made using SAP do not suffer from this mismatch. 4. Requirements and Recommendations The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use in an internetwork, although it is sufficiently general that it can describe conferences in other network environments. Media streams can be many-to-many. The times during which the session is active need not be continuous. Thus far, multicast based sessions on the Internet have differed from many other forms of conferencing in that anyone receiving the traffic can join the session (unless the session traffic is encrypted). In such an environment, SDP serves two primary purposes. It is a means to communicate the existence of a session, and is a means to convey sufficient information to enable joining and participating in the session. In a unicast environment, only the latter purpose is likely to be relevant. Thus SDP includes: o Session name and purpose o Time(s) the session is active o The media comprising the session o Information needed to receive those media (addresses, ports, formats and so on) As resources necessary to participate in a session may be limited, some additional information may also be desirable: o Information about the bandwidth to be used by the conference o Contact information for the person responsible for the session In general, SDP must convey sufficient information to enable applications to join a session (with the possible exception of encryption keys) and to announce the resources to be used to non- participants that may need to know. 4.1 Media Information SDP includes: o The type of media (video, audio, etc) o The transport protocol (RTP/UDP/IP, H.320, etc) o The format of the media (H.261 video, MPEG video, etc) For an IP multicast session, the following are also conveyed: o Multicast address for media o Transport port for media This address and port are the destination address and destination Handley, et al. Expires November 2, 2004 [Page 5] Internet-Draft SDP May 2004 port of the multicast stream, whether being sent, received, or both. For an IP unicast session, the following are conveyed: o Remote address for media o Transport port for media The semantics of this address and port depend on the media and transport protocol defined. By default, this is the remote address and remote port to which data is sent, however some media types may redefine this behaviour. 4.2 Timing Information Sessions may either be bounded or unbounded in time. Whether or not they are bounded, they may be only active at specific times. SDP can convey: o An arbitrary list of start and stop times bounding the session o For each bound, repeat times such as "every Wednesday at 10am for one hour" This timing information is globally consistent, irrespective of local time zone or daylight saving time. 4.3 Private Sessions It is possible to create both public sessions and private sessions. SDP itself does not distinguish between these: private sessions are typically conveyed by encrypting the session description during distribution. The details of how encryption is performed are dependent on the mechanism used to convey SDP - e.g. mechanisms are defined for SDP transported using SAP [8] and SIP [9]. If a session announcement is private it is possible to use that private announcement to convey encryption keys necessary to decode each of the media in a conference, including enough information to know which encryption scheme is used for each media. 4.4 Obtaining Further Information about a Session A session description should convey enough information to decide whether or not to participate in a session. SDP may include additional pointers in the form of Universal Resources Identifiers (URIs) for more information about the session. 4.5 Categorisation When many session descriptions are being distributed by SAP, or any other advertisement mechanism, it may be desirable to filter session announcements that are of interest from those that are not. SDP Handley, et al. Expires November 2, 2004 [Page 6] Internet-Draft SDP May 2004 supports a categorisation mechanism for sessions that is capable of being automated. 4.6 Internationalization The SDP specification recommends the use of the ISO 10646 character sets in the UTF-8 encoding [3] to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as ISO 8859-1 to be used when desired. Internationalization only applies to free-text fields (session name and background information), and not to SDP as a whole. 5. SDP Specification An SDP session description is denoted by the MIME content type "application/sdp" (See Section 9). An SDP session description is entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attribute names use only the US-ASCII subset of UTF-8, but textual fields and attribute values MAY use the full ISO 10646 character set. Field and attribute values which use the full UTF-8 character set are never directly compared, hence there is no requirement for UTF-8 normalization. The textual form, as opposed to a binary encoding such as ASN.1 or XDR, was chosen to enhance portability, to enable a variety of transports to be used (e.g, session description in a MIME email message) and to allow flexible, text-based toolkits (e.g., Tcl/ Tk) to be used to generate and to process session descriptions. However, since SDP may be used in environments where the maximum permissable size of a session description is limited (e.g. SAP announcements), the encoding is deliberately compact. Also, since announcements may be transported via very unreliable means or damaged by an intermediate caching server, the encoding was designed with strict order and formatting rules so that most errors would result in malformed session announcements which could be detected easily and discarded. This also allows rapid discarding of encrypted session announcements for which a receiver does not have the correct key. An SDP session description consists of a number of lines of text of the form: = where MUST be exactly one case-significant character and is structured text whose format depends on . In general is either a number of fields delimited by a single space character, or a free format string. Whitespace MUST NOT be used either side of the "=" sign. Handley, et al. Expires November 2, 2004 [Page 7] Internet-Draft SDP May 2004 An SDP session description consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a "v=" line and continues to the first media-level section. The media description starts with an "m=" line and continues to the next media description or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. Some lines in each description are REQUIRED and some are OPTIONAL but all MUST appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). OPTIONAL items are marked with a "*". Session description v= (protocol version) o= (owner/creator and session identifier). s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information - not required if included in all media) b=* (zero or more bandwidth information lines) One or more time descriptions (see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions (see below) Time description t= (time the session is active) r=* (zero or more repeat times) Media description m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines) The set of type letters is deliberately small and not intended to be extensible -- an SDP parser MUST completely ignore any session description that contains a type letter that it does not understand. The attribute mechanism ("a=" described below) is the primary means for extending SDP and tailoring it to particular applications or Handley, et al. Expires November 2, 2004 [Page 8] Internet-Draft SDP May 2004 media. Some attributes (the ones listed in Section 6 of this memo) have a defined meaning, but others may be added on an application-, media- or session-specific basis. An SDP parser MUST ignore any attribute it doesn't understand. An SDP session description may contain URIs which reference external content in the "u=", "k=" and "a=" lines. These URIs may be dereferenced in some cases, making the session description non-self contained. The connection ("c=") and attribute ("a=") information in the session-level section applies to all the media of that session unless overridden by connection information or an attribute of the same name in the media description. For instance, in the example below, each media behaves as if it were given a "recvonly" attribute. An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb a=orient:portrait Text fields such as the session name and information are octet strings which may contain any octet with the exceptions of 0x00 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers SHOULD be tolerant and also accept records terminated with a single newline character. If the "a=charset" attribute is not present, these octet strings MUST be interpreted as containing ISO-10646 characters in UTF-8 encoding (the presence of the "a=charset" attribute MAY force some fields to be interpreted differently). 5.1 Protocol Version ("v=") v=0 The "v=" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number. Handley, et al. Expires November 2, 2004 [Page 9] Internet-Draft SDP May 2004 5.2 Origin ("o=") o= The "o=" field gives the originator of the session (her username and the address of the user's host) plus a session identifier and version number: is the user's login on the originating host, or it is "-" if the originating host does not support the concept of user ids. The MUST NOT contain spaces. is a numeric string such that the tuple of , , , and form a globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) format timestamp be used to ensure uniqueness [7]. is a version number for this session description. Its usage is up to the creating tool, so long as is increased when a modification is made to the session data. Again, it is RECOMMENDED that an NTP format timestamp is used. is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in future (see Section 9). is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined, but other values MAY be registered in future (see Section 9). is the address of the machine from which the session was created. For an address type of IP4, this is either the fully-qualified domain name of the machine, or the dotted-decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully-qualified domain name of the machine, or the compressed textual representation of the IP version 6 address of the machine. For both IP4 and IP6, the fully-qualified domain name is the form that SHOULD be given unless this is unavailable, in which case the globally unique address MAY be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful. In general, the "o=" field serves as a globally unique identifier for this version of this session description, and the subfields excepting the version taken together identify the session irrespective of any modifications. Handley, et al. Expires November 2, 2004 [Page 10] Internet-Draft SDP May 2004 5.3 Session Name ("s=") s= The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s= " SHOULD be used (i.e. a single space as the session name). 5.4 Session Information ("i=") i= The "i=" field provides textual information about the session. There may be at most one session-level "i=" field per session description, and at most one "i=" field per media. If the "a=charset" attribute is present, it specifies the character set used in the "i=" field. If the "a=charset" attribute is not present, the "i=" field MUST contain ISO 10646 characters in UTF-8 encoding. A single "i=" field MAY also be used for each media definition. In media definitions, "i=" fields are primarily intended for labeling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions. 5.5 URI ("u=") u= A URI is a Universal Resource Identifier as used by WWW clients [4]. The URI should be a pointer to additional information about the conference. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI field is allowed per session description. 5.6 Email Address and Phone Number ("e=" and "p=") e= p= The "e=" and "p=" lines specify contact information for the person responsible for the conference. This is not necessarily the same person that created the conference announcement. Inclusion of an email address or phone number is OPTIONAL. Note that Handley, et al. Expires November 2, 2004 [Page 11] Internet-Draft SDP May 2004 the previous version of SDP specified that either an email field or a phone field MUST be specified, but this was widely ignored. The change brings the specification into line with common usage. If the email addres or phone number are present, they MUST be specified before the first media field. More than one email or phone field can be given for a session description. Phone numbers SHOULD be given in the form of an international public telecommunication number (see ITU-T Recommendation E.164) preceded by a "+". Spaces and hyphens may be used to split up a phone field to aid readability if desired. For example: p=+44-171-380-7777 or p=+1 617 555 6011 Both email addresses and phone numbers can have an OPTIONAL free text string associated with them, normally giving the name of the person who may be contacted. This MUST be enclosed in parenthesis if it is present. For example: e=j.doe@example.com (Jane Doe) The alternative RFC 2822 name quoting convention is also allowed for both email addresses and phone numbers. For example: e=Jane Doe The free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if the appropriate session-level "a=charset" attribute is set. 5.7 Connection Data ("c=") c= The "c=" field contains connection data. A session description MUST contain either at least one "c=" field in each media description or a single "c=" field at the session level. It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media. The first sub-field ("") is the network type, which is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 9). Handley, et al. Expires November 2, 2004 [Page 12] Internet-Draft SDP May 2004 The second sub-field ("") is the address type. This allows SDP to be used for sessions that are not IP based. Currently only IP4 and IP6 are defined, but other values MAY be registered in the future (see Section 9). The third sub-field ("") is the connection address. OPTIONAL sub-fields MAY be added after the connection address depending on the value of the field. When the is IP4 and IP6, the connection address is defined as follows: o If the session is multicast, the connection address will be an IP multicast group address. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields. It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited. o Conferences using an IPv4 multicast connection address MUST also have a time to live (TTL) value present in addition to the multicast address. The TTL and the address together define the scope with which multicast packets sent in this conference will be sent. TTL values MUST be in the range 0-255. The TTL for the session is appended to the address using a slash as a separator. An example is: c=IN IP4 224.2.36.42/127 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST NOT be present for IPv6 multicast. It is expected that IPv6 scoped addresses will be used to limit the scope of conferences. Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. The receiver can choose the desired quality (and hence bandwidth) by only subscribing to a subset of these layers. Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning. This technique keeps unwanted traffic from sites only requiring certain levels of the hierarchy. For applications requiring multiple multicast groups, we allow the following notation to be used for the connection address: [/]/ If the number of addresses is not given it is assumed to be one. Handley, et al. Expires November 2, 2004 [Page 13] Internet-Draft SDP May 2004 Multicast addresses so assigned are contiguously allocated above the base address, so that, for example: c=IN IP4 224.2.1.1/127/3 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to be used at a TTL of 127. This is semantically identical to including multiple "c=" lines in a media description: c=IN IP4 224.2.1.1/127 c=IN IP4 224.2.1.2/127 c=IN IP4 224.2.1.3/127 Similarly, an IPv6 example would be: c=IN IP6 FF15::101/3 which is semantically equivalent to: c=IN IP6 FF15::101 c=IN IP6 FF15::102 c=IN IP6 FF15::103 (remembering that the TTL field is not present in IPv6 multicast). Multiple addresses or "c=" lines MAY be specified on a per-media basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. They MUST NOT be specified for a session-level "c=" field. The slash notation described above MUST NOT be used for IP unicast addresses. 5.8 Bandwidth ("b=") b=: This OPTIONAL field denotes the proposed bandwidth to be used by the session or media. The is an alphanumeric modifier giving the meaning of the figure. Two values are initially defined, but other values MAY be registered in future (see Section 9): CT If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a "b=CT:..." line SHOULD be supplied for the session giving the proposed upper limit to the bandwidth used. The primary purpose of this is to give an approximate idea as to whether two or more sessions can co-exist Handley, et al. Expires November 2, 2004 [Page 14] Internet-Draft SDP May 2004 simultaneously. When using the CT modifier with RTP, if several RTP sessions are part of the conference, the conference total refers to total bandwidth of all RTP sessions. AS The bandwidth is interpreted to be application-specific (it will be the application's concept of maximum bandwidth). Normally this will coincide with what is set on the application's "maximum bandwidth" control if applicable. For RTP based applications, AS gives the RTP "session bandwidth" as defined in section 6.2 of [12]. Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending simultaneously. A prefix "X-" is defined for names. This is intended for experimental purposes only. For example: b=X-YZ:128 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers SHOULD be registered with IANA in the standard namespace. SDP parsers MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST be alpha-numeric and, although no length limit is given, they are recommended to be short. The is in kilobits per second by default. Modifiers MAY specify that alternative units are to be used (the modifiers defined in this memo use the default units). 5.9 Timing ("t=") t= The "t=" lines specify the start and stop times for a session. Multiple "t=" lines MAY be used if a session is active at multiple irregularly spaced times; each additional "t=" lines specifies an additional period of time for which the session will be active. If the session is active at regular times, an "r=" line (see below) should be used in addition to, and following, a "t=" line - in which case the "t=" line specifies the start and stop times of the repeat sequence. The first and second sub-fields give the start and stop times for the session respectively. These values are the decimal representation of Network Time Protocol (NTP) time values in seconds [7]. To convert these values to UNIX time, subtract decimal 2208988800. NTP timestamps are 64 bit values which wrap sometime in the year Handley, et al. Expires November 2, 2004 [Page 15] Internet-Draft SDP May 2004 2036. Since SDP uses an arbitrary length decimal representation, this should not cause an issue (SDP timestamps will continue counting seconds since 1900, NTP will use the value modulo the 64 bit limit). If the is set to zero, then the session is not bounded, though it will not become active until after the . If the is also zero, the session is regarded as permanent. User interfaces SHOULD strongly discourage the creation of unbounded and permanent sessions as they give no information about when the session is actually going to terminate, and so make scheduling difficult. The general assumption may be made, when displaying unbounded sessions that have not timed out to the user, that an unbounded session will only be active until half an hour from the current time or the session start time, whichever is the later. If behaviour other than this is required, an end-time should be given and modified as appropriate when new information becomes available about when the session should really end. Permanent sessions may be shown to the user as never being active unless there are associated repeat times which state precisely when the session will be active. In general, permanent sessions SHOULD NOT be created for any session expected to have a duration of less than 2 months, and should be discouraged for sessions expected to have a duration of less than 6 months. 5.10 Repeat Times ("r=") r= "r=" fields specify repeat times for a session. For example, if a session is active at 10am on Monday and 11am on Tuesday for one hour each week for three months, then the in the corresponding "t=" field would be the NTP representation of 10am on the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 hours. The corresponding "t=" field stop time would be the NTP representation of the end of the last session three months later. By default all fields are in seconds, so the "r=" and "t=" fields might be: t=3034423619 3042462419 r=604800 3600 0 90000 To make description more compact, times may also be given in units of days, hours or minutes. The syntax for these is a number immediately Handley, et al. Expires November 2, 2004 [Page 16] Internet-Draft SDP May 2004 followed by a single case-sensitive character. Fractional units are not allowed - a smaller unit should be used instead. The following unit specification characters are allowed: d - days (86400 seconds) h - hours (3600 seconds) m - minutes (60 seconds) s - seconds (allowed for completeness but not recommended) Thus, the above session announcement could also have been written: r=7d 1h 0 25h Monthly and yearly repeats cannot be directly specified with a single SDP repeat time - instead separate "t=" fields should be used to explicitly list the session times. 5.11 Time Zones ("z=") z= .... To schedule a repeated session which spans a change from daylight- saving time to standard time or vice-versa, it is necessary to specify offsets from the base time. This is required because different time zones change time at different times of day, different countries change to or from daylight time on different dates, and some countries do not have daylight saving time at all. Thus in order to schedule a session that is at the same time winter and summer, it must be possible to specify unambiguously by whose time zone a session is scheduled. To simplify this task for receivers, we allow the sender to specify the NTP time that a time zone adjustment happens and the offset from the time when the session was first scheduled. The "z=" field allows the sender to specify a list of these adjustment times and offsets from the base time. An example might be: z=2882844526 -1h 2898848070 0 This specifies that at time 2882844526 the time base by which the session's repeat times are calculated is shifted back by 1 hour, and that at time 2898848070 the session's original time base is restored. Adjustments are always relative to the specified start time - they are not cumulative. Adjustments apply to all "t=" and "r=" lines in a session description. If a session is likely to last several years, it is expected that the Handley, et al. Expires November 2, 2004 [Page 17] Internet-Draft SDP May 2004 session announcement will be modified periodically rather than transmit several years worth of adjustments in one session announcement. 5.12 Encryption Keys ("k=") k= k=: If transported over a secure and trusted channel, the session description protocol MAY be used to convey encryption keys. A simple mechanism for key exchange is provided by the key field ("k=") although this is primarily supported for compatibility with older implementations and its use is NOT RECOMMENDED. Work is in progress to define new key exchange mechanisms for use with SDP [17][16] and it is expected that new applications will use those mechanisms. A key field is permitted before the first media entry (in which case it applies to all media in the session), or for each media entry as required. The format of keys and their usage is outside the scope of this document, and the key field provides no way to indicate the encryption algorithm to be used, key type, or other information about the key: this is assumed to be provided by the higher-level protocol using SDP. If there is a need to convey this information within SDP, the extensions mentioned previously SHOULD be used. Many security protocols require two keys, one for confidentiality and another for integrity. This specification does not support the transfer of two keys. The method indicates the mechanism to be used to obtain a usable key by external means, or from the encoded encryption key given. The following methods are defined: Handley, et al. Expires November 2, 2004 [Page 18] Internet-Draft SDP May 2004 k=clear: The encryption key is included untransformed in this key field. This method MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure channel. k=base64: The encryption key is included in this key field but has been base64 encoded because it includes characters that are prohibited in SDP. This method MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure channel. k=uri: A Universal Resource Identifier is included in the key field. The URI refers to the data containing the key, and may require additional authentication before the key can be returned. When a request is made to the given URI, the reply should specify the encoding for the key. The URI is often a secure HTTP URI, although this is not required. k=prompt No key is included in this SDP description, but the session or media stream referred to by this key field is encrypted. The user should be prompted for the key when attempting to join the session, and this user-supplied key should then be used to decrypt the media streams. The use of user-specified keys is NOT RECOMMENDED, since such keys tend to have weak security properties. The key field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel. An example of such a channel might be SDP embedded inside an S/MIME message or a TLS protected HTTP or SIP session. It is important to ensure that the secure channel is with the party that is authorized to join the session, not an intermediary: if a caching proxy server is used, it is important to ensure that the proxy is either trusted or unable to access the SDP. Definition of appropriate security measures is beyond the scope of this specification, and should be defined by the users of SDP. 5.13 Attributes ("a=") a= a=: Handley, et al. Expires November 2, 2004 [Page 19] Internet-Draft SDP May 2004 Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. A media description may have any number of attributes ("a=" fields) which are media specific. These are referred to as "media-level" attributes and add information about the media stream. Attribute fields can also be added before the first media field; these "session-level" attributes convey additional information that applies to the conference as a whole rather than to individual media; an example might be the conference's floor control policy. Attribute fields may be of two forms: o property attributes: A property attribute is simply of the form "a=". These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session. An example might be "a=recvonly". o value attributes: A value attribute is of the form "a=:". For example, a whiteboard could have the value attribute "a=orient:landscape" Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular. Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. Attribute values are octet strings, and MAY use any octet value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are to be interpreted as in ISO-10646 character set with UTF-8 encoding. Unlike other text fields, attribute values are NOT normally affected by the "charset" attribute as this would make comparisons against known values problematic. However, when an attribute is defined, it can be defined to be charset-dependent, in which case it's value should be interpreted in the session charset rather than in ISO-10646. Attributes MUST be registered with IANA (see Section 9). If an attribute is received that is not understood, it MUST be ignored by the receiver. Handley, et al. Expires November 2, 2004 [Page 20] Internet-Draft SDP May 2004 5.14 Media Descriptions ("m=") m= A session description may contain a number of media descriptions. Each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field has several sub-fields. The first sub-field ("") is the media type. Currently defined media are "audio", "video", "text", "application", "data" and "control", though this list may be extended in future. The difference between "application" and "data" is that the former is a media flow such as whiteboard information, and the latter is bulk-data transfer such as multicasting of program executables which will not typically be displayed to the user. "control" is used to specify an additional conference control channel for the session. The second sub-field ("") is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=" field, and on the transport protocol defined in the third sub-field. Other ports used by the media application (such as the RTCP port [12]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (e.g. "a=rtcp:" as defined in [14]). For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "c=" field: m= / In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even numbered ports are used for data with the corresponding one-higher odd ports used for the RTCP belonging to the RTP session, and the denoting the number of RTP sessions. For example: m=video 49170/2 RTP/AVP 31 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below). If non- contiguous ports are required, they must be signalled using a separate attribute (e.g. "a=rtcp:" as defined in [14]). Handley, et al. Expires November 2, 2004 [Page 21] Internet-Draft SDP May 2004 If multiple addresses are specified in the "c=" field and multiple ports are specified in the "m=" field, a one-to-one mapping from port to the corresponding address is implied. For example: c=IN IP4 224.2.1.1/127/2 m=video 49170/2 RTP/AVP 31 would imply that address 224.2.1.1 is used with ports 49170 and 49171, and address 224.2.1.2 is used with ports 49172 and 49173. The third sub-field ("") is the transport protocol. The transport protocol values are dependent on the address type field in the "c=" fields. Thus a "c=" field of IP4 defines that the transport protocol runs over IP4. For IP4, it is normally expected that most media traffic will be carried as RTP over UDP. The following transport protocols are defined, but may be extended through registration of new protocols with IANA (see Section 9): RTP/AVP - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP. udp - User Datagram Protocol TCP - Transmission Control Protocol If an application uses a single combined proprietary media format and transport protocol over UDP, then simply specifying the transport protocol as udp and using the format field to distinguish the combined protocol is recommended. If a transport protocol is used over UDP to carry several distinct media types that need to be distinguished by a session directory, then specifying the transport protocol and media format separately is necessary. RTP is an example of a transport-protocol that carries multiple payload formats that must be distinguished by the session directory for it to know how to start appropriate tools, relays, mixers or recorders. The main reason to specify the transport-protocol in addition to the media format is that the same standard media formats may be carried over different transport protocols even when the network protocol is the same - a historical example is vat PCM audio and RTP PCM audio. In addition, relays and monitoring tools that are transport-protocol-specific but format-independent are possible. For RTP media streams operating under the RTP Audio/Video Profile [13], the protocol field is "RTP/AVP". Should other RTP profiles be defined in the future, their profiles will be specified in the same way. For example, the protocol field "RTP/XYZ" would specify RTP operating under a profile whose short name is "XYZ". The fourth and subsequent sub-fields ("") are media formats. Handley, et al. Expires November 2, 2004 [Page 22] Internet-Draft SDP May 2004 For audio, text and video, these SHOULD reference a MIME sub-type describing the format under the "audio", "text" and "video" top-level MIME types. When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats SHOULD be used as the default format for the session. For media whose transport protocol is not RTP or UDP the format field is protocol specific. Such formats should be defined in an additional specification document. For media whose transport protocol is RTP, SDP can be used to provide a dynamic binding of media encoding to RTP payload type. The encoding names in the RTP AV Profile do not specify unique audio encodings (in terms of clock rate and number of audio channels), and so they are not used directly in SDP format fields. Instead, the payload type number should be used to specify the format for static payload types and the payload type number along with additional encoding information should be used for dynamically allocated payload types. An example of a static payload type is u-law PCM coded single channel audio sampled at 8kHz. This is completely defined in the RTP Audio/ Video profile as payload type 0, so the media field for such a stream sent to UDP port 49232 is: m=audio 49232 RTP/AVP 0 An example of a dynamic payload type is 16 bit linear encoded stereo audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload type 98 for such a stream, additional information is required to decode it: m=audio 49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2 The general form of an rtpmap attribute is: a=rtpmap: / [/] For audio streams, may specify the number of audio channels. This parameter may be omitted if the number of channels is one provided no additional parameters are needed. For video streams, no encoding parameters are currently specified. Additional parameters may be defined in the future, but codec- Handley, et al. Expires November 2, 2004 [Page 23] Internet-Draft SDP May 2004 specific parameters SHOULD NOT be added. Parameters added to an rtpmap attribute SHOULD only be those required for a session directory to make the choice of appropriate media to participate in a session. Codec-specific parameters should be added in other attributes (for example, "a=fmtp:"). Up to one rtpmap attribute can be defined for each media format specified. Thus we might have: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 RTP profiles that specify the use of dynamic payload types MUST define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP. Note that RTP audio formats typically do not include information about the number of samples per packet. If a non-default (as defined in the RTP Audio/Video Profile) packetisation is required, the "ptime" attribute is used as given below. For more details on RTP audio and video formats, see [13]. Predefined application formats for the UDP protocol with non-RTP media are as below: wb: LBL Whiteboard (transport: udp) nt: UCL Network Text Editor (transport: udp) 6. Suggested Attributes The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. a=cat: This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter unwanted sessions by category. It is a session-level attribute, and is not dependent on charset. a=keywds: Like the cat attribute, this is to assist identifying wanted sessions at the receiver. This allows a receiver to select Handley, et al. Expires November 2, 2004 [Page 24] Internet-Draft SDP May 2004 interesting session based on keywords describing the purpose of the session. It is a session-level attribute. It is a charset dependent attribute, meaning that its value should be interpreted in the charset specified for the session description if one is specified, or by default in ISO 10646/UTF-8. a=tool: This gives the name and version number of the tool used to create the session description. It is a session-level attribute, and is not dependent on charset. a=ptime: This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data, but may be used with other media types if it makes sense. It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media attribute, and is not dependent on charset. a=maxptime: The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media attribute, and is not dependent on charset. Note that this attribute was introduced after RFC 2327, and non updated implementations will ignore this attribute. a=rtpmap: / [/] See Section 5.14. This may be a session or media attribute and is not dependent on charset. a=recvonly This specifies that the tools should be started in receive only mode where applicable. It can be either a session or media attribute, and is not dependent on charset. Note that recvonly applies to the media only, not to any associated Handley, et al. Expires November 2, 2004 [Page 25] Internet-Draft SDP May 2004 control protocol (e.g. an RTP based system in recvonly mode SHOULD still send RTCP packets). a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive only mode. It can be either a session or media attribute, and is not dependent on charset. If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present, "sendrecv" SHOULD be assumed as the default for sessions which are not of the conference type "broadcast" or "H332" (see below). a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be use, one sendonly and one recvonly. It can be either a session or media attribute, but would normally only be used as a media attribute, and is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g. RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP based system SHOULD still send RTCP, even if started inactive. It can be either a session or media attribute, and is not dependent on charset. a=orient: Normally this is only used in a whiteboard media specification. It specifies the orientation of a the whiteboard on the screen. It is a media attribute. Permitted values are "portrait", "landscape" and "seascape" (upside down landscape). It is not dependent on charset. a=type: This specifies the type of the conference. Suggested values are "broadcast", "meeting", "moderated", "test" and "H332". Handley, et al. Expires November 2, 2004 [Page 26] Internet-Draft SDP May 2004 "recvonly" should be the default for "type:broadcast" sessions, "type:meeting" should imply "sendrecv" and "type:moderated" should indicate the use of a floor control tool and that the media tools are started so as to mute new sites joining the conference. Specifying the attribute "type:H332" indicates that this loosely coupled session is part of a H.332 session as defined in the ITU H.332 specification [15]. Media tools should be started "recvonly". Specifying the attribute "type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users. The type attribute is a session-level attribute, and is not dependent on charset. a=charset: This specifies the character set to be used to display the session name and information data. By default, the ISO-10646 character set in UTF-8 encoding is used. If a more compact representation is required, other character sets may be used. For example, the ISO 8859-1 is specified with the following SDP attribute: a=charset:ISO-8859-1 This is a session-level attribute and is not dependent on charset. The charset specified MUST be one of those registered with IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and MUST be compared against the IANA identifiers using a case insensitive comparison. If the identifier is not recognised or not supported, all strings that are affected by it SHOULD be regarded as octet strings. Note that a character set specified MUST still prohibit the use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets requiring the use of these characters MUST define a quoting mechanism that prevents these bytes appearing within text fields. a=sdplang: This can be a session level attribute or a media level attribute. As a session level attribute, it specifies the language for the session description. As a media level Handley, et al. Expires November 2, 2004 [Page 27] Internet-Draft SDP May 2004 attribute, it specifies the language for any media-level SDP information field associated with that media. Multiple sdplang attributes can be provided either at session or media level if multiple languages in the session description or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media from most important to least important. In general, sending session descriptions consisting of multiple languages is discouraged. Instead, multiple descriptions SHOULD be sent describing the session, one in each language. However this is not possible with all transport mechanisms, and so multiple sdplang attributes are allowed although NOT RECOMMENDED. The "sdplang" attribute value must be a single RFC 3066 language tag in US-ASCII [6]. It is not dependent on the charset attribute. An "sdplang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. a=lang: This can be a session level attribute or a media level attribute. As a session level attribute, it specifies the default language for the session being described. As a media level attribute, it specifies the language for that media, overriding any session-level language specified. Multiple lang attributes can be provided either at session or media level if the session description or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media from most important to least important. The "lang" attribute value must be a single RFC 3066 language tag in US-ASCII [6]. It is not dependent on the charset attribute. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. a=framerate: This gives the maximum video frame rate in frames/sec. It is Handley, et al. Expires November 2, 2004 [Page 28] Internet-Draft SDP May 2004 intended as a recommendation for the encoding of video data. Decimal representations of fractional values using the notation "." are allowed. It is a media attribute, defined only for video media, and is not dependent on charset. a=quality: This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value in the range 0 to 10, with the following suggested meaning: 10 - the best still-image quality the compression scheme can give. 5 - the default behaviour given no quality suggestion. 0 - the worst still-image quality the codec designer thinks is still usable. It is a media attribute, and is not dependent on charset. a=fmtp: This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP doesn't have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. It is a media attribute, and is not dependent on charset. 7. Communicating Conference Control Policy There is some debate over the way conference control policy should be communicated. In general, the authors believe that an implicit declarative style of specifying conference control is desirable where possible. A simple declarative style uses a single conference attribute field before the first media field, possibly supplemented by properties such as `recvonly' for some of the media tools. This conference attribute conveys the conference control policy. An example might be: Handley, et al. Expires November 2, 2004 [Page 29] Internet-Draft SDP May 2004 a=type:moderated In some cases, however, it is possible that this may be insufficient to communicate the details of an unusual conference control policy. If this is the case, then a conference attribute specifying external control might be set, and then one or more "media" fields might be used to specify the conference control tools and configuration data for those tools. An example is an ITU H.332 session: ... c=IN IP4 224.5.6.7 a=type:H332 m=audio 49230 RTP/AVP 0 m=video 49232 RTP/AVP 31 m=application 12349 udp wb m=control 49234 H323 mc c=IN IP4 134.134.157.81 In this example, a general conference attribute (type:H332) is specified stating that conference control will be provided by an external H.332 tool, and a contact addresses for the H.323 session multipoint controller is given. In this document, only the declarative style of conference control declaration is specified. Other forms of conference control should specify an appropriate type attribute, and should define the implications this has for control media. 8. Security Considerations SDP is a session description format that describes multimedia sessions. A session description SHOULD NOT be trusted unless it has been obtained by an authenticated transport protocol from a trusted source. Many different transport protocols may be used to distribute session description, and the nature of the authentication will differ from transport to transport. One transport that will frequently be used to distribute session descriptions is the Session Announcement Protocol (SAP). SAP provides both encryption and authentication mechanisms but due to the nature of session announcements it is likely that there are many occasions where the originator of a session announcement cannot be authenticated because they are previously unknown to the receiver of the announcement and because no common public key infrastructure is available. On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, software parsing the session Handley, et al. Expires November 2, 2004 [Page 30] Internet-Draft SDP May 2004 should take a few precautions. Session descriptions contain information required to start software on the receivers system. Software that parses a session description MUST NOT be able to start other software except that which is specifically configured as appropriate software to participate in multimedia sessions. It is normally considered inappropriate for software parsing a session description to start, on a user's system, software that is appropriate to participate in multimedia sessions, without the user first being informed that such software will be started and giving their consent. Thus a session description arriving by session announcement, email, session invitation, or WWW page MUST NOT deliver the user into an interactive multimedia session unless the user has explicitly pre-authorized such action. As it is not always simple to tell whether a session is interactive or not, applications that are unsure should assume sessions are interactive. In this specification, there are no attributes which would allow the recipient of a session description to be informed to start multimedia tools in a mode where they default to transmitting. Under some circumstances it might be appropriate to define such attributes. If this is done an application parsing a session description containing such attributes SHOULD either ignore them, or inform the user that joining this session will result in the automatic transmission of multimedia data. The default behaviour for an unknown attribute is to ignore it. Session descriptions may be parsed at intermediate systems such as firewalls for the purposes of opening a hole in the firewall to allow the participation in multimedia sessions. It is considered inappropriate for a firewall to open such holes for unicast data streams unless the session description comes in a request from inside the firewall. For multicast sessions, it is likely that local administrators will apply their own policies, but the exclusive use of "local" or "site-local" administrative scope within the firewall and the refusal of the firewall to open a hole for such scopes will provide separation of global multicast sessions from local ones. Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. 9. IANA Considerations 9.1 The "application/sdp" media type One new MIME type is to be registered, as defined below. This updates the previous definition from RFC 2327. Handley, et al. Expires November 2, 2004 [Page 31] Internet-Draft SDP May 2004 To: ietf-types@iana.org Subject: Registration of MIME media type application/sdp MIME media type name: application MIME subtype name: sdp Required parameters: None. Optional parameters: None. Encoding considerations: See section 5 of RFC XXXX Security considerations: See section 8 of RFC XXXX Interoperability considerations: See RFC XXXX Published specification: RFC XXXX Applications which use this media type: Voice over IP, video teleconferencing, streaming media, instant messaging, etc. See also section 3 of RFC XXXX. Additional information: Magic number(s): None. File extension(s): The extension ".sdp" is commonly used. Macintosh File Type Code(s): "sdp " Person & email address to contact for further information: Colin Perkins IETF MMUSIC working group Intended usage: COMMON Author/Change controller: Authors of RFC XXXX IETF MMUSIC working group 9.2 Registration of Parameters There are seven field names that may be registered with IANA. Using Handley, et al. Expires November 2, 2004 [Page 32] Internet-Draft SDP May 2004 the terminology in the SDP specification BNF, they are "media", "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". 9.2.1 Media types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level MIME content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing MIME top-level content types, a standards-track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of RFC 2434 [5]. 9.2.2 Transport protocols ("proto") The "proto" field describes the transport protocol used. This SHOULD reference a standards-track protocol RFC. This memo registers three values: "RTP/AVP" is a reference to RTP [12] used under the RTP Profile for Audio and Video Conferences with Minimal Control [13] running over UDP/IP; "TCP" denotes an unspecified format over TCP; and "udp" indicates an unspecified format over UDP. New transport protocols MAY be registered with IANA. Registrations MUST reference an RFC describing the protocol. Such an RFC MAY be Experimental or Informational, although it is preferable if it is Standards-Track. Registrations MUST also define the rules by which their "fmt" namespace is managed (see below). 9.2.3 Media formats ("fmt") Each transport protocol, defined by the "proto" field, has an associated "fmt" namespace that describes the media formats which may conveyed by that protocol. Formats cover all the possible encodings that might want to be transported in a multimedia session. RTP payload formats under the "RTP/AVP" protocol that have been assigned static payload types MUST use the static payload type as their "fmt" value. For payload formats under "RTP/AVP" that have a dynamic payload type number, the dynamic payload type number is given as the "fmt" and an additional "rtpmap" attribute specifies the format name and parameters as defined by the MIME type registration for the payload format. For "TCP" and "udp" protocols, new formats SHOULD be registered. Use of an existing MIME subtype for the format is encouraged. If no MIME subtype exists, it is RECOMMENDED that a suitable one is registered Handley, et al. Expires November 2, 2004 [Page 33] Internet-Draft SDP May 2004 through the IETF process (RFC 2048) by production of, or reference to, a standards-track RFC. If a MIME subtype is for some reason inappropriate, an RFC publication describing the format MUST be referenced in the registration, but it may be Informational or Experimental if the protocol is not deemed to be of widespread deployment. For other protocols, formats MAY be registered according to the rules of the associated "proto" specification. Registrations of new formats MUST specify which transport protocols they apply to. 9.2.4 Attribute names ("att-field") Attribute field names ("att-field") MUST be registered with IANA and documented, because of noticeable issues due to conflicting attributes under the same name. Unknown attributes in SDP are simply ignored, but conflicting ones that fragment the protocol are a serious problem. New attribute registerations are accepted according to the "Specification Required" policy of RFC 2434, provided that the specification includes the following information: o contact name, email address and telephone number o attribute-name (as it will appear in SDP) o long-form attribute name in English o type of attribute (session level, media level, or both) o whether the attribute value is subject to the charset attribute. o a one paragraph explanation of the purpose of the attribute. o a specification of appropriate attribute values for this attribute. The above is the minimum that IANA will accept. Attributes that are expected to see widespread use and interoperability, SHOULD be documented with a standards-track RFC that specifies the attribute more precisely. Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability. IANA is requested to register the following initial set of attribute names ("att-field" values), with definitions as in Section 6 of this memo (these definitions update those in RFC 2327): Handley, et al. Expires November 2, 2004 [Page 34] Internet-Draft SDP May 2004 Name | Session or Media level? | Dependent on charset? ----------+-------------------------+---------------------- cat | Session | No keywds | Session | Yes tool | Session | No ptime | Media | No maxptime | Media | No rtpmap | Either | No recvonly | Either | No sendrecv | Either | No sendonly | Either | No inactive | Either | No orient | Media | No type | Session | No charset | Session | No sdplang | Either | No lang | Either | No framerate | Media | No quality | Media | No fmtp | Media | No 9.2.5 Bandwidth specifiers ("bwtype") A proliferation of bandwidth specifiers is strongly discouraged. New bandwidth specifiers ("bwtype" fields) MUST be registered with IANA. The submission MUST reference a standards-track RFC specifying the semantics of the bandwidth specifier precisely, and indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice. IANA is requested to register the bandwith specifiers "CT" and "AS" with definitions as in Section 5.8 of this memo (these definitions update those in RFC 2327). 9.2.6 Network types ("nettype") New network types (the "nettype" field) may be registered with IANA if SDP needs to be used in the context of non-Internet environments. Whilst these are not normally the preserve of IANA, there may be circumstances when an Internet application needs to interoperate with a non- Internet application, such as when gatewaying an Internet telephony call into the PSTN. The number of network types should be small and should be rarely extended. A new network type cannot be registered without registering at least one address type to be used with that network type. A new network type registration MUST reference an RFC which gives details of the network type and address Handley, et al. Expires November 2, 2004 [Page 35] Internet-Draft SDP May 2004 type and specifies how and when they would be used. Such an RFC MAY be Informational. IANA is requested to register the network type "IN" to represent the Internet, with definition as in Sections 5.2 and 5.7 of this memo (these definitions update those in RFC 2327). 9.2.7 Address types ("addrtype") New address types ("addrtype") may be registered with IANA. An address type is only meaningful in the context of a network type, and any registration of an address type MUST specify a registered network type, or be submitted along with a network type registration. A new address type registration MUST reference an RFC giving details of the syntax of the address type. Such an RFC MAY be Informational. Address types are not expected to be registered frequently. IANA is requested to register the address types "IP4" and "IP6" with definitions as in Sections 5.2 and 5.7 of this memo (these definitions update those in RFC 2327). 9.2.8 Registration Procedure In the RFC documentation that registers SDP "media", "proto", "fmt", "bwtype", "nettype" and "addrtype" fields, the authors MUST include the following information for IANA to place in the appropriate registry: o contact name, email address and telephone number o name being registered (as it will appear in SDP) o long-form name in English o type of name ("media", "proto", "fmt", "bwtype", "nettype", or "addrtype") o a one paragraph explanation of the purpose of the registered name. o a reference to the specification (e.g. RFC number) of the registered name. IANA may refer any registration to the IESG Transport Area Directors for review, and may request revisions to be made before a registration will be made. 9.3 Encryption Key Access Methods The IANA currently maintains a table of SDP encryption key access method ("enckey") names. This table is obsolete and SHOULD be removed, since the "k=" line is not extensible. New registrations MUST NOT be accepted. Handley, et al. Expires November 2, 2004 [Page 36] Internet-Draft SDP May 2004 Appendix A. SDP Grammar This appendix provides an Augmented BNF grammar for SDP. ABNF is defined in [2]. ; SDP Syntax session-description = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields connection-field bandwidth-fields time-fields key-field attribute-fields media-descriptions proto-version = "v=" 1*DIGIT CRLF ;this memo describes version 0 origin-field = "o=" username SP sess-id SP sess-version SP nettype SP addrtype SP unicast-address CRLF session-name-field = "s=" text CRLF information-field = ["i=" text CRLF] uri-field = ["u=" uri CRLF] email-fields = *("e=" email-address CRLF) phone-fields = *("p=" phone-number CRLF) connection-field = ["c=" nettype SP addrtype SP connection-address CRLF] ;a connection field must be present ;in every media description or at the ;session-level bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) time-fields = 1*( "t=" start-time SP stop-time *(CRLF repeat-fields) CRLF) [zone-adjustments CRLF] Handley, et al. Expires November 2, 2004 [Page 37] Internet-Draft SDP May 2004 repeat-fields = "r=" repeat-interval SP typed-time 1*(SP typed-time) zone-adjustments = "z=" time SP ["-"] typed-time *(SP time SP ["-"] typed-time) key-field = ["k=" key-type CRLF] attribute-fields = *("a=" attribute CRLF) media-descriptions = *( media-field information-field *connection-field bandwidth-fields key-field attribute-fields ) media-field = "m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF ; sub-rules of 'o=' username = non-ws-string ;pretty wide definition, but doesn't ;include space sess-id = 1*DIGIT ;should be unique for this username/host sess-version = 1*DIGIT ;0 is a new session nettype = token ;typically "IN" addrtype = token ;typically "IP4" or "IP6" ; sub-rules of 'u=' uri = URI-reference; see RFC1630 and RFC2732 ; sub-rules of 'e=' email-address = email *SP "(" 1*email-safe ")" / 1*email-safe "<" email ">" / email email = addr-spec ; defined in RFC2822 ; modified to remove CFWS Handley, et al. Expires November 2, 2004 [Page 38] Internet-Draft SDP May 2004 ; sub-rules of 'p=' phone-number = phone *SP "(" 1*email-safe ")" / 1*email-safe "<" phone ">" / phone phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT) ; sub-rules of 'c=' connection-address = multicast-address / unicast-address ; sub-rules of 'b=' bwtype = token bandwidth = 1*DIGIT ; sub-rules of 't=' start-time = time / "0" stop-time = time / "0" time = POS-DIGIT 9*DIGIT ; 10-digit NTP time represents times between ; 1931 and 5068 AD. 9* allows times after ; that as well. ; sub-rules of 'r=' and 'z=' repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] typed-time = 1*DIGIT [fixed-len-time-unit] fixed-len-time-unit = "d" / "h" / "m" / "s" ; sub-rules of 'k=' key-type = "prompt" / "clear:" text / "base64:" base64 / "uri:" uri / key-method [ ":" text ] base64 = *base64-unit [base64-pad] base64-unit = 4base64-char base64-pad = 2base64-char "==" / 3base64-char "=" base64-char = ALPHA / DIGIT / "+" / "/" key-method = token ; sub-rules of 'a=' attribute = (att-field ":" att-value) / att-field Handley, et al. Expires November 2, 2004 [Page 39] Internet-Draft SDP May 2004 att-field = token att-value = byte-string ; sub-rules of 'm=' media = token ;typically "audio", "video", "text", ;"application" or "data" fmt = token ;typically an RTP payload type for audio ;and video media proto = token "/" token / token ;typically "RTP/AVP", "udp" or "tcp" port = 1*DIGIT ;should be either "0" or in the range "1024" ;to "65535" inclusive for UDP based media ;(a value of "0" is used to signal special ;conditions in some uses of SDP) ; generic sub-rules: addressing unicast-address = IP4-address / IP6-address / FQDN / extn-addr multicast-address = IP4-multicast / IP6-multicast IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" integer ] ; IPv4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = hexpart [ "/" integer ] ; IPv6 address starting with FF ttl = (POS-DIGIT *2DIGIT) / "0" FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified ; in RFC1035 IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" b1 = decimal-uchar Handley, et al. Expires November 2, 2004 [Page 40] Internet-Draft SDP May 2004 ; less than "224"; not "0" or "127" ; The following is from RFC2373 Appendix B. It is a direct copy. IP6-address = hexpart [ ":" IP4-address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG ; Generic for other address families extn-addr = non-ws-string ; generic sub-rules: datatypes text = byte-string ;default is to interpret this as UTF8 text. ;ISO 8859-1 requires "a=charset:ISO-8859-1" ;session-level attribute to be used byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR or LF non-ws-string = 1*(VCHAR/%x80-FF) ;string of visible characters token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E token = 1*(token-char) email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF ;any byte except NUL, CR, LF, or the quoting ;characters ()<> integer = POS-DIGIT *DIGIT ; generic sub-rules: primitives alpha-numeric = ALPHA / DIGIT POS-DIGIT = %x31-39 ; 1 - 9 decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2*(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) Handley, et al. Expires November 2, 2004 [Page 41] Internet-Draft SDP May 2004 ; external references: ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 ; URI-reference: from RFC1630 and RFC2732 ; addr-spec: from RFC 2822 Appendix B. Acknowledgments Many people in the IETF MMUSIC working group have made comments and suggestions contributing to this document. In particular, we would like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, Jonathan Lennox and Keith Drage. 10. References 10.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [6] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. 10.2 Informative References [7] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Handley, et al. Expires November 2, 2004 [Page 42] Internet-Draft SDP May 2004 [10] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. [14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [15] International Telecommunications Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998. [16] Arkko, J., "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October 2003. [17] Andreasen, F., Baugher, M. and D. Wing, "SDP Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-02 (work in progress), October 2003. Authors' Addresses Mark Handley University College London Gower Street London WC1E 6BT UK EMail: M.Handley@cs.ucl.ac.uk Handley, et al. Expires November 2, 2004 [Page 43] Internet-Draft SDP May 2004 Van Jacobson Packet Design 2465 Latham Street Mountain View, CA 94040 USA EMail: van@packetdesign.com Colin Perkins University of Glasgow 17 Lilybank Gardens Glasgow G12 8QQ UK EMail: csp@csperkins.org Handley, et al. Expires November 2, 2004 [Page 44] Internet-Draft SDP May 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Handley, et al. Expires November 2, 2004 [Page 45] --Boundary-00=_EZhmAGu7QzIWJzj-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 07:43:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07451 for ; Thu, 6 May 2004 07:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLhEZ-0007Y9-PT for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 07:40:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46BeBd7028988 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 07:40:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLh5T-0004O0-11 for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 07:30:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06761 for ; Thu, 6 May 2004 07:30:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLh5S-0005Ox-H8 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 07:30:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLh4i-0004z8-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 07:30:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLh3p-0004Zd-0A for mmusic-web-archive@ietf.org; Thu, 06 May 2004 07:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgwz-00014O-1b; Thu, 06 May 2004 07:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgo3-0006ZF-Nt for mmusic@optimus.ietf.org; Thu, 06 May 2004 07:12:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06212 for ; Thu, 6 May 2004 07:12:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLgo3-00067S-8s for mmusic@ietf.org; Thu, 06 May 2004 07:12:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgn2-0005ij-00 for mmusic@ietf.org; Thu, 06 May 2004 07:11:44 -0400 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1BLgmT-0005JA-00 for mmusic@ietf.org; Thu, 06 May 2004 07:11:09 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 14:10:32 +0300 Message-ID: From: "Even, Roni" To: "'Mark Handley'" , Colin Perkins Cc: "Rod.Walsh" , van , mmusic , "magnus.westerlund" Subject: RE: [MMUSIC] Re: sdp-new unregistered media types Date: Thu, 6 May 2004 14:10:32 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, If you deprecate the data and control MIME type that will take away the defined distinction between application data and control in 5.14. So everything that is not audio video or text will be application. For example if we want to add far end camera control will it be application. Does that make sense or do we still want to enable such distinctions. Roni ************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-55-481099 email:roni.even@polycom.co.il ******************************************* -----Original Message----- From: Mark Handley [mailto:M.Handley@cs.ucl.ac.uk] Sent: Thursday, May 06, 2004 12:47 PM To: Colin Perkins Cc: Rod.Walsh; van; mmusic; magnus.westerlund Subject: [MMUSIC] Re: sdp-new unregistered media types >On Thursday 06 May 2004 10:18, Rod.Walsh@nokia.com wrote: >> Is Magnus's suggestion, to 'depreciate' "data" and "control" from SDP >> until they are IANA registered, feasible or likely? > >I submitted -16 yesterday, without making that change. Unless there is >strong consensus from the group to do so, I wish to avoid changes that are >not backwards compatible. Does anyone use "data" and "control"? The IANA considerations (at least in -15) only specify a SHOULD for these matching the top level MIME types: 9.2.1 Media types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level MIME content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing MIME top-level content types, a standards-track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of RFC 2434 [5].' So the lack of a MIME Content Type for these isn't a problem, but there should be a way to register media formats under these with IANA - I believe currently there isn't. But if there's no interoperability report for "data" and "control", they should clearly be deprecated before moving to draft standard. BTW, the first part of section 9 refers to a future registration of application/sdp, but this is already registered, so if you haven't already removed in from -16, you probably should do so. Cheers, Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 08:53:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10162 for ; Thu, 6 May 2004 08:53:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiIM-0006gq-Hr for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 08:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46CmA5o025711 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 08:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiHE-0005km-De for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 08:47:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09716 for ; Thu, 6 May 2004 08:46:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLiHD-000448-50 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:46:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiGJ-0003e4-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:46:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLiFb-0003E9-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLi6i-0001nR-1a; Thu, 06 May 2004 08:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLi2O-0008To-1m for mmusic@optimus.ietf.org; Thu, 06 May 2004 08:31:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09020 for ; Thu, 6 May 2004 08:31:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLi2M-0005cP-Qa for mmusic@ietf.org; Thu, 06 May 2004 08:31:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLi1P-0005Ed-00 for mmusic@ietf.org; Thu, 06 May 2004 08:30:39 -0400 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 1BLi0Q-0004pw-00 for mmusic@ietf.org; Thu, 06 May 2004 08:29:38 -0400 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.9p2/8.12.8) with ESMTP id i46CTZxF019016; Thu, 6 May 2004 13:29:36 +0100 (BST) (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: "Even, Roni" cc: Colin Perkins , "Rod.Walsh" , mmusic , "magnus.westerlund" Subject: Re: [MMUSIC] Re: sdp-new unregistered media types In-reply-to: Your message of "Thu, 06 May 2004 14:10:32 +0300." Date: Thu, 06 May 2004 13:29:35 +0100 Message-ID: <19015.1083846575@aardvark.cs.ucl.ac.uk> Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >If you deprecate the data and control MIME type that will take away the >defined distinction between application data and control in 5.14. So >everything that is not audio video or text will be application. >For example if we want to add far end camera control will it be application. >Does that make sense or do we still want to enable such distinctions. application as a MIME type is something of a catchall - it really should be called "misc" in my opinion. For example, SDP's MIME type is application/sdp Now SDP isn't really an application, and it isn't really application data - it's really control data or metadata. I added "control" (long before SDP types were associated with MIME types) because I prefered to make the distinction between data and metadata - I thought and still think adds clarity. But the arguments both for and against are not really strong. Now, as to IETF process: - if "control" isn't being used in an interoperable manner, we can't progress it to draft standard. - if "control" is being used in an interoperable manner by a few people, we should not deprecate it. The IANA considerations for SDP are entirely consistent with not needed to have a MIME type for this, although there should be a registry for the media formats. - if the use of "control" is widespread, we should probably push for a MIME Content Type to be registered for it. I assume Colin probably knows best what the current deployment status is, so I won't comment on that. - Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 09:01:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10514 for ; Thu, 6 May 2004 09:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiS0-0001aP-8N for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 08:58:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46Cw8lw006054 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 08:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiMj-0007oq-B7 for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 08:52:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10121 for ; Thu, 6 May 2004 08:52:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLiMi-0006Yk-18 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:52:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiLk-000693-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:51:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLiKk-0005j9-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:50:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiHH-0005lO-CE; Thu, 06 May 2004 08:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLi8R-00029e-BC for mmusic@optimus.ietf.org; Thu, 06 May 2004 08:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09468 for ; Thu, 6 May 2004 08:37:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLi8Q-0000SL-3L for mmusic@ietf.org; Thu, 06 May 2004 08:37:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLi7k-00003R-00 for mmusic@ietf.org; Thu, 06 May 2004 08:37:12 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BLi6x-0007OC-00 for mmusic@ietf.org; Thu, 06 May 2004 08:36:23 -0400 Received: from mangole ([130.209.247.112]:65120) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BLi6Q-0004NL-00; Thu, 06 May 2004 13:35:50 +0100 From: Colin Perkins Organization: http://csperkins.org To: Mark Handley Subject: Re: [MMUSIC] Re: sdp-new unregistered media types Date: Thu, 6 May 2004 13:35:50 +0100 User-Agent: KMail/1.6.2 Cc: "Even, Roni" , "Rod.Walsh" , mmusic , "magnus.westerlund" References: <19015.1083846575@aardvark.cs.ucl.ac.uk> In-Reply-To: <19015.1083846575@aardvark.cs.ucl.ac.uk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405061335.50075.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 06 May 2004 13:29, Mark Handley wrote: > >If you deprecate the data and control MIME type that will take away the > >defined distinction between application data and control in 5.14. So > >everything that is not audio video or text will be application. > >For example if we want to add far end camera control will it be > > application. Does that make sense or do we still want to enable such > > distinctions. > > application as a MIME type is something of a catchall - it really > should be called "misc" in my opinion. > > For example, SDP's MIME type is application/sdp > Now SDP isn't really an application, and it isn't really application > data - it's really control data or metadata. > > I added "control" (long before SDP types were associated with MIME > types) because I prefered to make the distinction between data and > metadata - I thought and still think adds clarity. But the arguments > both for and against are not really strong. > > > Now, as to IETF process: > > - if "control" isn't being used in an interoperable manner, we can't > progress it to draft standard. > > - if "control" is being used in an interoperable manner by a few > people, we should not deprecate it. The IANA considerations for > SDP are entirely consistent with not needed to have a MIME type for > this, although there should be a registry for the media formats. > > - if the use of "control" is widespread, we should probably push for > a MIME Content Type to be registered for it. > > > I assume Colin probably knows best what the current deployment status > is, so I won't comment on that. Actually, if people are using "control" or "data", it would be helpful if they could speak out. :) Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 09:02:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10586 for ; Thu, 6 May 2004 09:02:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiS7-0001eV-4u for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 08:58:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46CwF3M006346 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 08:58:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiPf-0008Im-NN for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 08:55:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10271 for ; Thu, 6 May 2004 08:55:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLiPe-00000d-Es for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:55:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiOk-0007Pe-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:54:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLiNu-00070R-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 08:53:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiJB-00071v-Jz; Thu, 06 May 2004 08:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiH7-0005kQ-4z for mmusic@optimus.ietf.org; Thu, 06 May 2004 08:46:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09690 for ; Thu, 6 May 2004 08:46:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLiH5-00043D-RT for mmusic@ietf.org; Thu, 06 May 2004 08:46:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiGC-0003d1-00 for mmusic@ietf.org; Thu, 06 May 2004 08:45:56 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BLiFF-0002ot-00; Thu, 06 May 2004 08:44:57 -0400 Received: from mangole ([130.209.247.112]:51005) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BLiEh-0004RC-00; Thu, 06 May 2004 13:44:23 +0100 From: Colin Perkins Organization: http://csperkins.org To: mmusic@ietf.org Subject: Re: [MMUSIC] SDP Session Description for FLUTE Sessions Date: Thu, 6 May 2004 13:44:23 +0100 User-Agent: KMail/1.6.2 Cc: Rod.Walsh@nokia.com, , , , , , , , References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405061344.23536.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 06 May 2004 10:44, Rod.Walsh@nokia.com wrote: > To summarise the discussion so far: > > Media descriptions (a "m=" line and a "a=" line) can be used to specify > the group/destination address & port of FLUTE session channels. > > We need a new protocol id for FLUTE. It will be either FLUTE/UDP or > UDP/FLUTE and the difference seems trivial to implementations. > > We need to understand how media types work with FLUTE. It is possible to > allow any media types (of SDP and IANA) as long at the FLUTE transported > files adhere to this. It is also possible to recommend that > "application" media is used. I think that sometimes allowing a MIME content type, and sometimes using "m=data" will be very confusing. We should have a single definition, if possible. > The can be used to specify the reciever application type (e.g. > "wb" for whiteboard). A "null" (i.e. dummy) fmt value could be used to > say 'the application has to work out the file MIME types some other > way', which is the expected use in many cases. FLUTE's FDT is one way to > do this. An out-of-flute-session-band method would also be desirable to > allow a multitude of different content-specialised FLUTE receiver > applications on a host, but it seems that this is out of SDP 'for FLUTE' > scope. Why? If there is a need for an out-of-band way of conveying FDT, then it would seem that SDP is an appropriate place to put it. > I've seen "0" used for a fmt "null" value - is that common > practice? I'd prefer something like "-" to make it clear this is distinct from a MIME sub-type or RTP payload type number. > So we might be looking at... > m=application 32416 FLUTE/UDP 0 > a= > ...in a typical case. Note, "m=data..." is also on the cards for the > typical case. > > > Personally I see: > > m=data 32416 FLUTE/UDP 0 > for generic FLUTE receivers which are distinct from the user rendering > interface... > > m=application 32416 FLUTE/UDP 0 > for generic FLUTE receivers which include the user rendering interface, > so "integtrated multimedia applciations"... > > m=application 32416 FLUTE/UDP pdf > m=video 32416 FLUTE/UDP mpeg > for homogeneous single content-specific FLUTE sessions How are these different at the protocol level? > Unfortunately, except in extremely tightly controlled closed systems, a > FLUTE sender would not require the first two to be differentiated (it's > upto the reciever to deal with mixed content), so both "data" or > "application + fmt=null" will mean exactly the same thing. Which would imply that we should have a single way of signalling this, no? -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 09:20:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11498 for ; Thu, 6 May 2004 09:20:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLii9-0007UM-6U for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 09:14:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46DEn9x028774 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 09:14:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLidC-0005en-IB for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 09:09:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10983 for ; Thu, 6 May 2004 09:09:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLidB-0005ed-6N for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:09:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLicF-0005Fe-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:08:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLibB-0004og-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:07:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiWj-0003J3-0i; Thu, 06 May 2004 09:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiSb-0001il-93 for mmusic@optimus.ietf.org; Thu, 06 May 2004 08:58:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10378 for ; Thu, 6 May 2004 08:58:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLiSZ-0001DN-Rw for mmusic@ietf.org; Thu, 06 May 2004 08:58:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiRg-0000p7-00 for mmusic@ietf.org; Thu, 06 May 2004 08:57:49 -0400 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1BLiRJ-0000Pa-00 for mmusic@ietf.org; Thu, 06 May 2004 08:57:25 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 15:56:47 +0300 Message-ID: From: "Even, Roni" To: "'Colin Perkins'" , Mark Handley Cc: "Even, Roni" , "Rod.Walsh" , mmusic , "magnus.westerlund" Subject: RE: [MMUSIC] Re: sdp-new unregistered media types Date: Thu, 6 May 2004 15:56:46 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, My comment is that if data and control are detracted then section 5.14 should be changed to say that application is used for all those cases. Otherwise I do not have a problem with data or control. Roni Even -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Thursday, May 06, 2004 3:36 PM To: Mark Handley Cc: Even, Roni; Rod.Walsh; mmusic; magnus.westerlund Subject: Re: [MMUSIC] Re: sdp-new unregistered media types On Thursday 06 May 2004 13:29, Mark Handley wrote: > >If you deprecate the data and control MIME type that will take away the > >defined distinction between application data and control in 5.14. So > >everything that is not audio video or text will be application. > >For example if we want to add far end camera control will it be > > application. Does that make sense or do we still want to enable such > > distinctions. > > application as a MIME type is something of a catchall - it really > should be called "misc" in my opinion. > > For example, SDP's MIME type is application/sdp > Now SDP isn't really an application, and it isn't really application > data - it's really control data or metadata. > > I added "control" (long before SDP types were associated with MIME > types) because I prefered to make the distinction between data and > metadata - I thought and still think adds clarity. But the arguments > both for and against are not really strong. > > > Now, as to IETF process: > > - if "control" isn't being used in an interoperable manner, we can't > progress it to draft standard. > > - if "control" is being used in an interoperable manner by a few > people, we should not deprecate it. The IANA considerations for > SDP are entirely consistent with not needed to have a MIME type for > this, although there should be a registry for the media formats. > > - if the use of "control" is widespread, we should probably push for > a MIME Content Type to be registered for it. > > > I assume Colin probably knows best what the current deployment status > is, so I won't comment on that. Actually, if people are using "control" or "data", it would be helpful if they could speak out. :) Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 09:25:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11751 for ; Thu, 6 May 2004 09:25:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiqV-0001rd-GN for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 09:23:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46DNRwP007153 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 09:23:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLijF-0007uf-QG for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 09:15:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11295 for ; Thu, 6 May 2004 09:15:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLijE-0000Ia-90 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:15:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLii9-0007gn-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:14:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLihV-0007IJ-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:14:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLicX-0005Ms-5p; Thu, 06 May 2004 09:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiYR-0003tU-CX for mmusic@optimus.ietf.org; Thu, 06 May 2004 09:04:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10754 for ; Thu, 6 May 2004 09:04:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLiYP-0003di-PS for mmusic@ietf.org; Thu, 06 May 2004 09:04:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiXO-0003E5-00 for mmusic@ietf.org; Thu, 06 May 2004 09:03:43 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BLiWJ-0002SH-00 for mmusic@ietf.org; Thu, 06 May 2004 09:02:35 -0400 Received: from mangole ([130.209.247.112]:65321) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BLiVn-0004bk-00; Thu, 06 May 2004 14:02:03 +0100 From: Colin Perkins Organization: http://csperkins.org To: "Even, Roni" Subject: Re: [MMUSIC] Re: sdp-new unregistered media types Date: Thu, 6 May 2004 14:02:02 +0100 User-Agent: KMail/1.6.2 Cc: mmusic References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405061402.02879.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [cc list trimmed] On Thursday 06 May 2004 13:56, Even, Roni wrote: > My comment is that if data and control are detracted then section 5.14 > should be changed to say that application is used for all those cases. > Otherwise I do not have a problem with data or control. Do you know of implementations using "data" or "control"? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 09:26:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11813 for ; Thu, 6 May 2004 09:26:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiqz-00029r-DL for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 09:23:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46DNv1c008290 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 09:23:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLins-0000bz-NY for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 09:20:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11479 for ; Thu, 6 May 2004 09:20:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLinq-0002GK-VS for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:20:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLims-0001rX-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:19:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLilv-0001TY-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 09:18:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLigQ-0006tv-0P; Thu, 06 May 2004 09:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLibK-0004zp-OP for mmusic@optimus.ietf.org; Thu, 06 May 2004 09:07:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10890 for ; Thu, 6 May 2004 09:07:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLibJ-0004rV-8l for mmusic@ietf.org; Thu, 06 May 2004 09:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiaL-0004Sd-00 for mmusic@ietf.org; Thu, 06 May 2004 09:06:46 -0400 Received: from bzq-179-16-107.cust.bezeqint.net ([212.179.16.107] helo=accord-mail.israel.polycom.com) by ietf-mx with esmtp (Exim 4.12) id 1BLiZR-0003fh-00 for mmusic@ietf.org; Thu, 06 May 2004 09:05:50 -0400 Received: by accord-mail.israel.polycom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 16:05:08 +0300 Message-ID: From: "Even, Roni" To: "'Colin Perkins'" , "Even, Roni" Cc: mmusic Subject: RE: [MMUSIC] Re: sdp-new unregistered media types Date: Thu, 6 May 2004 16:05:07 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Colin, No, the only data application I know is T.120 and I saw application used for that. Like I mentioned, my intention is to write a draft for far end camera control similar to what H.323 annex Q and I do not mind using application as the media type Roni -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Thursday, May 06, 2004 4:02 PM To: Even, Roni Cc: mmusic Subject: Re: [MMUSIC] Re: sdp-new unregistered media types [cc list trimmed] On Thursday 06 May 2004 13:56, Even, Roni wrote: > My comment is that if data and control are detracted then section 5.14 > should be changed to say that application is used for all those cases. > Otherwise I do not have a problem with data or control. Do you know of implementations using "data" or "control"? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 11:30:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20258 for ; Thu, 6 May 2004 11:30:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkhx-0002Rk-GC for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 11:22:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46FMjoL009390 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 11:22:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkeF-000159-UA for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 11:18:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19548 for ; Thu, 6 May 2004 11:18:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLkeF-0005wE-3S for mmusic-web-archive@ietf.org; Thu, 06 May 2004 11:18:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLkdK-0005Wp-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 11:17:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLkci-000573-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 11:17:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkWc-0006xI-I0; Thu, 06 May 2004 11:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkOf-0003xP-Mq for mmusic@optimus.ietf.org; Thu, 06 May 2004 11:02:49 -0400 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18669 for ; Thu, 6 May 2004 11:02:45 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BLkMM-0002Xm-Rc; Thu, 06 May 2004 11:00:26 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , mmusic mailing list , mmusic chair , mmusic chair Message-Id: Date: Thu, 06 May 2004 11:00:26 -0400 Subject: [MMUSIC] Protocol Action: 'A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)' to Proposed Standard Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) ' as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary Although the Session Description Protocol (SDP) already has a "bandwidth" parameter(the b= line) to characterize the amount of bandwidth a particular session will require, it is difficult for the receiver of an SDP message to know what values the creator of SDP used to factor the overhead into the total session bandwidth value. This becomes especially problematic in the presence of middleboxes that convert between IPv4 and IPv6. The use of session header compression (such as cRTP) on a per-hop basis at the sender side can also confuse recipients of SDP, since the assessment of total bandwidth on the sender side will assume header compression that probably isn't available at the receiver side. Similar problems exist for calculating RTCP bandwidth. Accordingly, this document defines a Transport Independent Application Specific Maximum (TIAS) bandwidith modifier that can appear in the b= line o SDP, and a new attribute, "maxrate", that is correlated with SDP media (m=) lines. Together, these two parameters enable recipients of SDP to make a muc more exact and universal assessment of the bandwidth that a session will require. Working Group Summary This MMUSIC Working Group supported the advancement of this specification. Protocol Quality This document has been reviewed for the IESG by Jon Peterson. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 13:35:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05944 for ; Thu, 6 May 2004 13:35:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmaV-0004tt-7Q for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 13:23:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HNBBE018836 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 13:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmAf-0003ZM-3c for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 12:56:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00134 for ; Thu, 6 May 2004 12:56:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLmAd-0000bR-Dl for mmusic-web-archive@ietf.org; Thu, 06 May 2004 12:56:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLm9S-00003V-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 12:55:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLm8H-0007Jc-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 12:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlMx-0006wy-8L; Thu, 06 May 2004 12:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkrs-0006Cb-Q4 for mmusic@optimus.ietf.org; Thu, 06 May 2004 11:33:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20424; Thu, 6 May 2004 11:32:58 -0400 (EDT) Message-Id: <200405061532.LAA20424@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 06 May 2004 11:32:58 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP: Session Description Protocol Author(s) : M. Handley, et al. Filename : draft-ietf-mmusic-sdp-new-16.txt Pages : 45 Date : 2004-5-5 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-new-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-new-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-6113527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-new-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-new-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113527.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 6 13:48:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06818 for ; Thu, 6 May 2004 13:48:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmfZ-0000Af-9b for mmusic-archive@odin.ietf.org; Thu, 06 May 2004 13:28:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HSPDH000652 for mmusic-archive@odin.ietf.org; Thu, 6 May 2004 13:28:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmPo-0004gB-53 for mmusic-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02220 for ; Thu, 6 May 2004 13:12:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLmPm-0000Uo-Bt for mmusic-web-archive@ietf.org; Thu, 06 May 2004 13:12:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmMu-0006sj-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 13:09:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLmKb-0005hL-00 for mmusic-web-archive@ietf.org; Thu, 06 May 2004 13:06:45 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLmAt-0001wg-Gi for mmusic-web-archive@ietf.org; Thu, 06 May 2004 12:56:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlN0-0006y0-Ij; Thu, 06 May 2004 12:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLksQ-0006GO-Rc for mmusic@optimus.ietf.org; Thu, 06 May 2004 11:33:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20435; Thu, 6 May 2004 11:33:32 -0400 (EDT) Message-Id: <200405061533.LAA20435@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 06 May 2004 11:33:32 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdescriptions-04.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Session Description Protocol Security Descriptions for Media Streams Author(s) : F. Andreasen, et al. Filename : draft-ietf-mmusic-sdescriptions-04.txt Pages : 36 Date : 2004-5-5 This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdescriptions-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-6113536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdescriptions-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113536.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 05:54:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11691 for ; Fri, 7 May 2004 05:54:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1yg-000342-7X for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 05:49:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i479nABb011776 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 05:49:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1sN-0008SM-3Z for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 05:42:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10672 for ; Fri, 7 May 2004 05:42:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM1sJ-00007T-L7 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 05:42:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM1rF-0007Tf-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 05:41:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM1pc-0006fi-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 05:39:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1en-0003yK-Jp; Fri, 07 May 2004 05:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM0eC-0008N9-Ab for mmusic@optimus.ietf.org; Fri, 07 May 2004 04:23:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07819 for ; Fri, 7 May 2004 04:23:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM0e9-000768-Bq for mmusic@ietf.org; Fri, 07 May 2004 04:23:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM0cx-0006SG-00 for mmusic@ietf.org; Fri, 07 May 2004 04:22:39 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BM0bZ-0005RS-00 for mmusic@ietf.org; Fri, 07 May 2004 04:21:14 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63097 helo=[192.168.0.3]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BM0b2-000058-00 for mmusic@ietf.org; Fri, 07 May 2004 09:20:40 +0100 From: Colin Perkins Organization: http://csperkins.org To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Date: Fri, 7 May 2004 09:20:40 +0100 User-Agent: KMail/1.6.2 References: <200405061532.LAA20424@ietf.org> In-Reply-To: <200405061532.LAA20424@ietf.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405070920.40362.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiparty Multimedia > Session Control Working Group of the IETF. > > Title : SDP: Session Description Protocol > Author(s) : M. Handley, et al. > Filename : draft-ietf-mmusic-sdp-new-16.txt > Pages : 45 > Date : 2004-5-5 > > This memo defines the Session Description Protocol (SDP). SDP is > intended for describing multimedia sessions for the purposes of > session announcement, session invitation, and other forms of > multimedia session initiation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt Changes in this version: - Add support for "text" media - Add the Macintosh File Type Code to the MIME registration - Add IANA registrations for attributes and parameters defined herein - Delete the definition "session advertisment" from section 2. - Make use of the terms "session announcement" and "session description" consistent - Remove recommendations on use of SDP with SAP from definition of "i=" since they duplicated RFC 2974 - Reference RFC 2822 rather than RFC 822 - Clarify that the free-text name associated with email address and phone number MUST be enclosed in parenthesis, to match the ABNF. - Clarify that the X- prefix for bandwidth modifier names is for experimental purposes only - Rename the top-level construct in the ABNF to "session-description" rather than "announcement" - Remove duplicate definition of "multimedia session" from section 4 - Clarify that the "conventional international format" for phone numbers is an E.164 number in section 5.6. Relax (poorly defined) requirement for a space or hyphen between the country code and the rest of the phone number. - Clarify which attributes and fields are dependent on charset - Better align the ABNF field names and those in the main document -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 06:17:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13532 for ; Fri, 7 May 2004 06:17:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM2OO-0004Wt-Dm for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 06:15:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47AFiCj017401 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 06:15:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM2KM-0002FN-Gz for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 06:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13194 for ; Fri, 7 May 2004 06:11:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM2KI-0004lC-NW for mmusic-web-archive@ietf.org; Fri, 07 May 2004 06:11:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM2Iw-0004AL-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 06:10:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM2Gg-0003Ba-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 06:07:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM2C4-0007bi-TO; Fri, 07 May 2004 06:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLoBF-0004bY-40 for mmusic@optimus.ietf.org; Thu, 06 May 2004 15:05:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11446 for ; Thu, 6 May 2004 15:05:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLoBC-0001vd-5M for mmusic@ietf.org; Thu, 06 May 2004 15:05:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLoAE-0001V7-00 for mmusic@ietf.org; Thu, 06 May 2004 15:04:10 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLo9U-0000ne-00 for mmusic@ietf.org; Thu, 06 May 2004 15:03:24 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i46J0YLc022969; Thu, 6 May 2004 14:00:34 -0500 (CDT) Received: from ericsson.com (rvi2-93-91.sw.ericsson.se [153.88.93.91]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWK008F; Thu, 6 May 2004 14:00:19 -0500 Message-ID: <409A8B4F.7000806@ericsson.com> Date: Thu, 06 May 2004 22:00:31 +0300 X-Sybari-Trust: 86c9aa91 08d63d2e 7e64d14e 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rod.Walsh@nokia.com CC: dku@tzi.org, jon.peterson@neustar.biz, fandreas@cisco.com, dwing@cisco.com, mbaugher@cisco.com, magnus.westerlund@ericsson.com, jari.arkko@ericsson.com, elisabetta.carrara@ericsson.com, fredrik.lindholm@ericsson.com, mats.naslund@ericsson.com, karl.norrman@ericsson.com, jo@tzi.uni-bremen.de, nom@flab.fujitsu.co.jp, schulzrinne@cs.columbia.edu, Hitoshi.Asaeda@sophia.inria.fr, csp@csperkins.org, juha-pekka.luoma@nokia.com, mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: FW: Security requirements review Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, a couple of comments: I would clarify what you had in mind when you wrote the following requirement: REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust resources of IMG entities by flooding them with IMG metadata. What do you mean by "avoid"? Do you mean that the entity should be able to run in a stateless mode? Or that it should be able to identify evil packets and discard their data? or...? You should clarify both requirements in Section 6.5 (Replay Attacks): REQ REP-1: IMG metadata MUST be protected against partial or full replacement of newer ("current") versions by older ones. REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on the IMG operations. Do you mean that you have to bundle somehow the metadata with the delivery mechanism? Let's say I receive metadata and I send it to another user without knowing that a newer version of the metadata is available... should the other user be able to detect this "reply attack"? I guess that an explanatory paragraph would help understand what these requirements really mean. Thanks, Gonzalo Rod.Walsh@nokia.com wrote: > Hi > > Because I found that you have somehow been active on security issues related to MMUSIC, it would be fantastic if you would have a look at the security requirements in: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-03.txt > ..and send comments back (CC MMUSIC email list too if possible). > > The document concerns "Requirements for Internet Media Guides" (IMGs). > > This document has completed WGLC and we are thinking about a final sanity check that nothing crazy slipped past the authors, reviewers and numerous editions before handing over to the IESG (as a kindness towards the IESG :) If you spot any impossible, unnecessary or questionable requirements please highlight them. (Naturally we're happy that the document is flawless, but once by your expert eyes would be very reassuring). > > The security sanity check concerns chapter 6 of the document (maybe I'm pushing my luck to say comments on other parts are always welcome too). > > Thanks for any ideas you can offer. > > Cheers, Rod Walsh. > > > PS rather than filling your inbox with lots of background I hope you are happy to ask in case you haven't had chance to follow the IMG work so far. > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 10:50:36 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28164 for ; Fri, 7 May 2004 10:50:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM6Zb-0004Lk-KQ for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 10:43:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47EhZ7H016719 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 10:43:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM63A-00064u-GV for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23572 for ; Fri, 7 May 2004 10:10:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM638-0004Fr-Dt for mmusic-web-archive@ietf.org; Fri, 07 May 2004 10:10:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM62D-0003nJ-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 10:09:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM61H-0003LU-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 10:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5tc-0007Oc-PQ; Fri, 07 May 2004 10:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM2I1-0001gk-CD for mmusic@optimus.ietf.org; Fri, 07 May 2004 06:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12480 for ; Fri, 7 May 2004 06:09:04 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM2Hx-0003g4-Cs for mmusic@ietf.org; Fri, 07 May 2004 06:09:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM2FV-0002zY-00 for mmusic@ietf.org; Fri, 07 May 2004 06:06:34 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BM2ET-0002PB-00; Fri, 07 May 2004 06:05:29 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i47A5MH15588; Fri, 7 May 2004 13:05:22 +0300 (EET DST) X-Scanned: Fri, 7 May 2004 13:04:22 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i47A4LXB018044; Fri, 7 May 2004 13:04:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00tV3AGy; Fri, 07 May 2004 13:03:31 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i47A3VH06098; Fri, 7 May 2004 13:03:31 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 May 2004 13:03:31 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 May 2004 13:03:31 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 May 2004 13:03:30 +0300 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 Subject: RE: [MMUSIC] SDP Session Description for FLUTE Sessions Date: Fri, 7 May 2004 13:03:30 +0300 Message-ID: Thread-Topic: [MMUSIC] SDP Session Description for FLUTE Sessions Thread-Index: AcQzZ/G6qal23oZaS/a/FS3MrtwAVgArHTWQ To: Cc: , , , , , , , , X-OriginalArrivalTime: 07 May 2004 10:03:30.0603 (UTC) FILETIME=[8C9BC7B0:01C4341A] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Please see in-line... > From: ext Colin Perkins [mailto:csp@csperkins.org] > I think that sometimes allowing a MIME content type, and=20 > sometimes using=20 > "m=3Ddata" will be very confusing. We should have a single=20 > definition, if=20 > possible. It boils down to what is needed to configure the FLUTE receiver = application. For mixed content FLUTE receivers a we need to have = "content is mixed or unspecified" description (either "m=3Ddata" or = "m=3Dapplication" with null fmt would do the job. For single content = session receivers (e.g. a video player) we could allow multiple media = types which may simplify receiver operation but does complicate = (confuse) the SDP. I think this would be fine to only allow "mixed = content" media type. Is anyone unhappy if we only allow "mixed content" media type (in the = m=3D"media type") and disallow specifics (audio, video, ...)? > > do this. An out-of-flute-session-band method would also be=20 > desirable to > > allow a multitude of different content-specialised FLUTE receiver > > applications on a host, but it seems that this is out of=20 > SDP 'for FLUTE' > > scope.=20 > Why? If there is a need for an out-of-band way of conveying=20 > FDT, then it=20 > would seem that SDP is an appropriate place to put it. My applications need to specify it outside of the FLUTE session SDP = anyway (and not bound to SDP syntax). In general, content selection = preceeds session configuration and initiation so allowing content = description within SDP (to bind content and session) solves only a = subset of use cases (not that it isn't a good idea to support = communication of content-type capability requirements). FLUTE itself can = give you this information in the FDT Instances (XML descriptions of the = files in in the FLUTE session). Allowing a URI (in the SDP) to point to content descriptions would be = sufficient for the FLUTE usage I anticipate, but if someone has a = practical (not only theroetical) need to describe content-types in FLUTE = sessions for capability description I would be interested. (Note, I do = not believe describing the files themsleves in the SDP is a sensible = approach, even when they are known sufficiently in advance to make this = possible.) > > I've seen "0" used for a fmt "null" value - is that common=20 > I'd prefer something like "-" to make it clear this is=20 > distinct from a MIME=20 > sub-type or RTP payload type number. "-" it is - any objections? Would we need to IANA register this or just = add to sdp-new? On this subject, it seems fine to include "-" in a list so as to = partially specify media types, e.g. =3D "sdp xml - zip" (if = sdp were the default). Comments? > > m=3Ddata 32416 FLUTE/UDP 0 > > for generic FLUTE receivers which are distinct from the=20 > user rendering > > interface... > > > > m=3Dapplication 32416 FLUTE/UDP 0 > > for generic FLUTE receivers which include the user=20 > rendering interface, so "integtrated multimedia applciations"... > > > > m=3Dapplication 32416 FLUTE/UDP pdf > > m=3Dvideo 32416 FLUTE/UDP mpeg > How are these different at the protocol level? No difference at transport protocol level, only at paylaod (file) type. > > Unfortunately, except in extremely tightly controlled=20 > closed systems, a > > FLUTE sender would not require the first two to be=20 > differentiated (it's > > upto the reciever to deal with mixed content), so both "data" or > > "application + fmt=3Dnull" will mean exactly the same thing. > Which would imply that we should have a single way of=20 > signalling this, no? Yes. And the only problem with this is the SDP (and sdp-new) comparative = description of data and application. To allow only application, would = this changed sdp-new description be feasible: The difference between "application" and "data" is that the former is a = media flow, which may or may not be displayed to the user, such as = whiteboard information. The latter is bulk-data transfer such as = multicasting of program executables which will not typically be = displayed to the user.=20 If "data" were deprecited that would also solve the problem. Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 13:01:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05666 for ; Fri, 7 May 2004 13:01:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8bj-0000B3-K1 for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 12:53:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Grt5b000679 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 12:53:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8Wz-00072g-Tb for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 12:49:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04809 for ; Fri, 7 May 2004 12:48:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM8Wy-00063r-9P for mmusic-web-archive@ietf.org; Fri, 07 May 2004 12:49:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8W4-0005df-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 12:48:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM8VS-0005D8-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 12:47:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8OS-0004Ps-4A; Fri, 07 May 2004 12:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM8Eq-0000R0-34 for mmusic@optimus.ietf.org; Fri, 07 May 2004 12:30:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04031 for ; Fri, 7 May 2004 12:30:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM8Eo-0005R6-K5 for mmusic@ietf.org; Fri, 07 May 2004 12:30:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM8Do-000502-00 for mmusic@ietf.org; Fri, 07 May 2004 12:29:13 -0400 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1BM8Cu-000471-00 for mmusic@ietf.org; Fri, 07 May 2004 12:28:16 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id i47GROWe083256; Fri, 7 May 2004 09:27:25 -0700 (PDT) (envelope-from casner@acm.org) Date: Fri, 7 May 2004 09:27:23 -0700 (PDT) From: Stephen Casner To: Rod.Walsh@nokia.com cc: mmusic@ietf.org Subject: RE: [MMUSIC] SDP Session Description for FLUTE Sessions In-Reply-To: Message-ID: <20040507091532.V80683@oak.packetdesign.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 7 May 2004 Rod.Walsh@nokia.com wrote: > > From: ext Colin Perkins [mailto:csp@csperkins.org] > > I think that sometimes allowing a MIME content type, and sometimes > > using "m=data" will be very confusing. We should have a single > > definition, if possible. > > It boils down to what is needed to configure the FLUTE receiver > application. For mixed content FLUTE receivers a we need to have > "content is mixed or unspecified" description (either "m=data" or > "m=application" with null fmt would do the job. For single content > session receivers (e.g. a video player) we could allow multiple > media types which may simplify receiver operation but does > complicate (confuse) the SDP. I think this would be fine to only > allow "mixed content" media type. > > Is anyone unhappy if we only allow "mixed content" media type (in > the m="media type") and disallow specifics (audio, video, ...)? Well, the original design and application of SDP in the MBone was to allow selection of the right application to receive an advertised stream. Mark Handley has made this point on numerous occasions in the past. There is a distinction between the information needed to select the right receiving application, and then the details that the application needs to configure itself. We get into trouble because that boundary is not always clear, or not the same over the space of all applications. To answer specifically for FLUTE, is it likely that there will be different applications to be invoked for receiving video via FLUTE versus, say, file download? My guess is the answer would be yes. So, unless the expected design for FLUTE applications is that there would be some front end that is required to be able to receive (or at least consider receiving) anything, and it is responsible for dispatching to another level, I think we need to make a distinction at the SDP level. In particular, if there is a video simulcast with multiple transmission methods, one of which is FLUTE and the other is some other protocol, and I have a FLUTE file download receiver on my box but no capability to receive video via FLUTE, I might not be able to make an informed decision about which of the simulcast streams to choose. -- Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 15:11:31 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14222 for ; Fri, 7 May 2004 15:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAcy-00012p-Mx for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 15:03:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47J3K20004016 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 15:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAW0-0003ec-SA for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 14:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12330 for ; Fri, 7 May 2004 14:56:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMAVy-0000bG-1l for mmusic-web-archive@ietf.org; Fri, 07 May 2004 14:56:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAV0-0000AF-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 14:55:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMAUF-0007X4-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 14:54:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAKJ-00005e-J3; Fri, 07 May 2004 14:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMAFW-0006u5-AJ for mmusic@optimus.ietf.org; Fri, 07 May 2004 14:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11147 for ; Fri, 7 May 2004 14:39:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMAFT-0000ZK-Im for mmusic@ietf.org; Fri, 07 May 2004 14:39:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMAEk-00009s-00 for mmusic@ietf.org; Fri, 07 May 2004 14:38:19 -0400 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1BMADr-0007Ni-00 for mmusic@ietf.org; Fri, 07 May 2004 14:37:23 -0400 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 11:36:52 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 May 2004 11:36:52 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 11:36:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Date: Fri, 7 May 2004 11:36:51 -0700 Message-ID: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt thread-index: AcQ0F0Z26qoAoqeiQrCToCB9BQPAIAASOWvw From: "Orit Levin" To: "Colin Perkins" , Cc: "Gonzalo Camarillo" , "Alan Johnston" , "Rohan Mahy" X-OriginalArrivalTime: 07 May 2004 18:36:35.0731 (UTC) FILETIME=[39F98630:01C43462] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Colin and all, In the process of our work on conferencing and other "transcoder" applications (in both SIPPING and XCON), we have (re-)identified the need for labeling of media streams. I have almost finished writing a MMUSIC draft that would introduce "a label" to a media stream when I came across the statement below in your draft under the "Session Information": " A single "i=3D" field MAY also be used for each media definition. In media definitions, "i=3D" fields are primarily intended for labeling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions. " Based on this, would you expect that automata will use this information or do we still need to add a "label-id" media attributes with the semantics similar to "info" but for automata use. Thanks, Orit. -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of Colin Perkins Sent: Friday, May 07, 2004 1:21 AM To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. This draft is a work item of the Multiparty Multimedia=20 > Session Control Working Group of the IETF. > > Title : SDP: Session Description Protocol > Author(s) : M. Handley, et al. > Filename : draft-ietf-mmusic-sdp-new-16.txt > Pages : 45 > Date : 2004-5-5 > > This memo defines the Session Description Protocol (SDP). SDP is=20 > intended for describing multimedia sessions for the purposes of=20 > session announcement, session invitation, and other forms of=20 > multimedia session initiation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt Changes in this version: - Add support for "text" media - Add the Macintosh File Type Code to the MIME registration - Add IANA registrations for attributes and parameters defined herein - Delete the definition "session advertisment" from section 2. - Make use of the terms "session announcement" and "session description" consistent - Remove recommendations on use of SDP with SAP from definition of = "i=3D" since they duplicated RFC 2974 - Reference RFC 2822 rather than RFC 822 - Clarify that the free-text name associated with email address and phone number MUST be enclosed in parenthesis, to match the ABNF. - Clarify that the X- prefix for bandwidth modifier names is for experimental purposes only - Rename the top-level construct in the ABNF to "session-description" rather than "announcement" - Remove duplicate definition of "multimedia session" from section 4 - Clarify that the "conventional international format" for phone numbers is an E.164 number in section 5.6. Relax (poorly defined) requirement for a space or hyphen between the country code and the rest of the phone number. - Clarify which attributes and fields are dependent on charset - Better align the ABNF field names and those in the main document -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 16:01:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17078 for ; Fri, 7 May 2004 16:01:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBSz-0006EO-7N for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 15:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47Jv5O6023953 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 15:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBP3-0005G5-6w for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 15:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16676 for ; Fri, 7 May 2004 15:52:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBP1-00027I-LC for mmusic-web-archive@ietf.org; Fri, 07 May 2004 15:52:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBO4-0001gh-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 15:52:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMBMy-00013V-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 15:50:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBJG-0003pe-3f; Fri, 07 May 2004 15:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMBGO-0002O9-C7 for mmusic@optimus.ietf.org; Fri, 07 May 2004 15:44:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16329 for ; Fri, 7 May 2004 15:44:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMBGM-000662-U0 for mmusic@ietf.org; Fri, 07 May 2004 15:44:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMBFX-0005ga-00 for mmusic@ietf.org; Fri, 07 May 2004 15:43:12 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BMBF4-0005FW-00 for mmusic@ietf.org; Fri, 07 May 2004 15:42:42 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i47JdQLc000696; Fri, 7 May 2004 14:39:26 -0500 (CDT) Received: from ericsson.com (rvi2-93-19.sw.ericsson.se [153.88.93.19]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLB0VW; Fri, 7 May 2004 14:39:10 -0500 Message-ID: <409BE5EF.7030401@ericsson.com> Date: Fri, 07 May 2004 22:39:27 +0300 X-Sybari-Trust: f87a39ef 08d63d2e c6d8b62b 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Colin Perkins , mmusic@ietf.org, Alan Johnston , Rohan Mahy Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit, the intention of the i= line is to provide human readable information. That is, it is not intended for automata. We ran into the same question when designing the grouping stuff and decided to define the mid attributes for the same reason. Regards, Gonzalo Orit Levin wrote: > Colin and all, > In the process of our work on conferencing and other "transcoder" > applications (in both SIPPING and XCON), we have (re-)identified the > need for labeling of media streams. I have almost finished writing a > MMUSIC draft that would introduce "a label" to a media stream when I > came across the statement below in your draft under the "Session > Information": > > " A single "i=" field MAY also be used for each media definition. In > media definitions, "i=" fields are primarily intended for labeling > media streams. As such, they are most likely to be useful when a > single session has more than one distinct media stream of the same > media type. An example would be two different whiteboards, one for > slides and one for feedback and questions. > " > > Based on this, would you expect that automata will use this information > or do we still need to add a "label-id" media attributes with the > semantics similar to "info" but for automata use. > > Thanks, > Orit. > > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of > Colin Perkins > Sent: Friday, May 07, 2004 1:21 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt > > On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. This draft is a work item of the Multiparty Multimedia >>Session Control Working Group of the IETF. >> >> Title : SDP: Session Description Protocol >> Author(s) : M. Handley, et al. >> Filename : draft-ietf-mmusic-sdp-new-16.txt >> Pages : 45 >> Date : 2004-5-5 >> >>This memo defines the Session Description Protocol (SDP). SDP is >>intended for describing multimedia sessions for the purposes of >>session announcement, session invitation, and other forms of >>multimedia session initiation. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt > > > Changes in this version: > - Add support for "text" media > - Add the Macintosh File Type Code to the MIME registration > - Add IANA registrations for attributes and parameters defined herein > - Delete the definition "session advertisment" from section 2. > - Make use of the terms "session announcement" and "session description" > consistent > - Remove recommendations on use of SDP with SAP from definition of "i=" > since they duplicated RFC 2974 > - Reference RFC 2822 rather than RFC 822 > - Clarify that the free-text name associated with email address and > phone > number MUST be enclosed in parenthesis, to match the ABNF. > - Clarify that the X- prefix for bandwidth modifier names is for > experimental purposes only > - Rename the top-level construct in the ABNF to "session-description" > rather than "announcement" > - Remove duplicate definition of "multimedia session" from section 4 > - Clarify that the "conventional international format" for phone numbers > is an E.164 number in section 5.6. Relax (poorly defined) requirement > for a space or hyphen between the country code and the rest of the > phone > number. > - Clarify which attributes and fields are dependent on charset > - Better align the ABNF field names and those in the main document > > -- > Colin Perkins > http://csperkins.org/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 17:28:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21939 for ; Fri, 7 May 2004 17:28:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCee-0003Pk-1P for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 17:13:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47LDCxt013119 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 17:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCcb-0002c1-Cq for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 17:11:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21088 for ; Fri, 7 May 2004 17:11:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMCcZ-00051q-7B for mmusic-web-archive@ietf.org; Fri, 07 May 2004 17:11:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMCbd-0004a8-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 17:10:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMCal-00041H-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 17:09:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCUn-0000LC-Gl; Fri, 07 May 2004 17:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMCO9-0006S3-OD for mmusic@optimus.ietf.org; Fri, 07 May 2004 16:56:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20117 for ; Fri, 7 May 2004 16:56:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMCO7-0006O9-Gz for mmusic@ietf.org; Fri, 07 May 2004 16:56:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMCNA-0005xF-00 for mmusic@ietf.org; Fri, 07 May 2004 16:55:09 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BMCME-00057k-00 for mmusic@ietf.org; Fri, 07 May 2004 16:54:10 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63840 helo=[192.168.0.3]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BMCLi-0004p5-00; Fri, 07 May 2004 21:53:38 +0100 From: Colin Perkins Organization: http://csperkins.org To: Gonzalo Camarillo Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Date: Fri, 7 May 2004 21:53:38 +0100 User-Agent: KMail/1.6.2 Cc: Orit Levin , mmusic@ietf.org, Alan Johnston , Rohan Mahy References: <409BE5EF.7030401@ericsson.com> In-Reply-To: <409BE5EF.7030401@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405072153.38796.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Gonzalo - the "i=" line is human readable information, not something that can be processed by automata. Colin On Friday 07 May 2004 20:39, Gonzalo Camarillo wrote: > Orit, > > the intention of the i= line is to provide human readable information. > That is, it is not intended for automata. > > We ran into the same question when designing the grouping stuff and > decided to define the mid attributes for the same reason. > > Regards, > > Gonzalo > > Orit Levin wrote: > > Colin and all, > > In the process of our work on conferencing and other "transcoder" > > applications (in both SIPPING and XCON), we have (re-)identified the > > need for labeling of media streams. I have almost finished writing a > > MMUSIC draft that would introduce "a label" to a media stream when I > > came across the statement below in your draft under the "Session > > Information": > > > > " A single "i=" field MAY also be used for each media definition. In > > media definitions, "i=" fields are primarily intended for labeling > > media streams. As such, they are most likely to be useful when a > > single session has more than one distinct media stream of the same > > media type. An example would be two different whiteboards, one for > > slides and one for feedback and questions. > > " > > > > Based on this, would you expect that automata will use this > > information or do we still need to add a "label-id" media attributes > > with the semantics similar to "info" but for automata use. > > > > Thanks, > > Orit. > > > > -----Original Message----- > > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf > > Of Colin Perkins > > Sent: Friday, May 07, 2004 1:21 AM > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt > > > > On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. This draft is a work item of the Multiparty Multimedia > >>Session Control Working Group of the IETF. > >> > >> Title : SDP: Session Description Protocol > >> Author(s) : M. Handley, et al. > >> Filename : draft-ietf-mmusic-sdp-new-16.txt > >> Pages : 45 > >> Date : 2004-5-5 > >> > >>This memo defines the Session Description Protocol (SDP). SDP is > >>intended for describing multimedia sessions for the purposes of > >>session announcement, session invitation, and other forms of > >>multimedia session initiation. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt > > > > Changes in this version: > > - Add support for "text" media > > - Add the Macintosh File Type Code to the MIME registration > > - Add IANA registrations for attributes and parameters defined herein > > - Delete the definition "session advertisment" from section 2. > > - Make use of the terms "session announcement" and "session > > description" consistent > > - Remove recommendations on use of SDP with SAP from definition of > > "i=" since they duplicated RFC 2974 > > - Reference RFC 2822 rather than RFC 822 > > - Clarify that the free-text name associated with email address and > > phone > > number MUST be enclosed in parenthesis, to match the ABNF. > > - Clarify that the X- prefix for bandwidth modifier names is for > > experimental purposes only > > - Rename the top-level construct in the ABNF to "session-description" > > rather than "announcement" > > - Remove duplicate definition of "multimedia session" from section 4 > > - Clarify that the "conventional international format" for phone > > numbers is an E.164 number in section 5.6. Relax (poorly defined) > > requirement for a space or hyphen between the country code and the > > rest of the phone > > number. > > - Clarify which attributes and fields are dependent on charset > > - Better align the ABNF field names and those in the main document > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 17:57:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23178 for ; Fri, 7 May 2004 17:57:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDJy-0007Sd-Po for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 17:55:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47LtsX0028670 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 17:55:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDFc-00064c-M4 for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 17:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22884 for ; Fri, 7 May 2004 17:51:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMDFa-0006k0-1A for mmusic-web-archive@ietf.org; Fri, 07 May 2004 17:51:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDEb-0006IC-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 17:50:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMDDt-0005rd-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 17:49:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDBN-0004qu-0Q; Fri, 07 May 2004 17:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMD4i-0002sv-R1 for mmusic@optimus.ietf.org; Fri, 07 May 2004 17:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22444 for ; Fri, 7 May 2004 17:40:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMD4g-0001zQ-AN for mmusic@ietf.org; Fri, 07 May 2004 17:40:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMD3e-0001YP-00 for mmusic@ietf.org; Fri, 07 May 2004 17:39:03 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BMD2Y-0000i1-00 for mmusic@ietf.org; Fri, 07 May 2004 17:37:54 -0400 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 14:37:31 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 7 May 2004 14:37:06 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 May 2004 14:37:23 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 14:37:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Date: Fri, 7 May 2004 14:37:21 -0700 Message-ID: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt thread-index: AcQ0dV1zFBxLAdgoRxioce3qoWHmpQABX/PA From: "Orit Levin" To: "Colin Perkins" , "Gonzalo Camarillo" Cc: , "Alan Johnston" , "Rohan Mahy" X-OriginalArrivalTime: 07 May 2004 21:37:22.0664 (UTC) FILETIME=[7B402680:01C4347B] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks a lot! So I am continuing with our joint with Gonzalo draft which will define a new label ("l=3D") media attribute being used by automata. I hope that we all agree that there is a need for this attribute in SDP for conferencing and transcoding applications. Orit. -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: Friday, May 07, 2004 1:54 PM To: Gonzalo Camarillo Cc: Orit Levin; mmusic@ietf.org; Alan Johnston; Rohan Mahy Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt I agree with Gonzalo - the "i=3D" line is human readable information, = not something that can be processed by automata. Colin On Friday 07 May 2004 20:39, Gonzalo Camarillo wrote: > Orit, > > the intention of the i=3D line is to provide human readable = information. > That is, it is not intended for automata. > > We ran into the same question when designing the grouping stuff and > decided to define the mid attributes for the same reason. > > Regards, > > Gonzalo > > Orit Levin wrote: > > Colin and all, > > In the process of our work on conferencing and other "transcoder" > > applications (in both SIPPING and XCON), we have (re-)identified the > > need for labeling of media streams. I have almost finished writing a > > MMUSIC draft that would introduce "a label" to a media stream when I > > came across the statement below in your draft under the "Session > > Information": > > > > " A single "i=3D" field MAY also be used for each media definition. In > > media definitions, "i=3D" fields are primarily intended for labeling > > media streams. As such, they are most likely to be useful when a > > single session has more than one distinct media stream of the same > > media type. An example would be two different whiteboards, one for > > slides and one for feedback and questions. > > " > > > > Based on this, would you expect that automata will use this > > information or do we still need to add a "label-id" media attributes > > with the semantics similar to "info" but for automata use. > > > > Thanks, > > Orit. > > > > -----Original Message----- > > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf > > Of Colin Perkins > > Sent: Friday, May 07, 2004 1:21 AM > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt > > > > On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. This draft is a work item of the Multiparty Multimedia > >>Session Control Working Group of the IETF. > >> > >> Title : SDP: Session Description Protocol > >> Author(s) : M. Handley, et al. > >> Filename : draft-ietf-mmusic-sdp-new-16.txt > >> Pages : 45 > >> Date : 2004-5-5 > >> > >>This memo defines the Session Description Protocol (SDP). SDP is > >>intended for describing multimedia sessions for the purposes of > >>session announcement, session invitation, and other forms of > >>multimedia session initiation. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt > > > > Changes in this version: > > - Add support for "text" media > > - Add the Macintosh File Type Code to the MIME registration > > - Add IANA registrations for attributes and parameters defined herein > > - Delete the definition "session advertisment" from section 2. > > - Make use of the terms "session announcement" and "session > > description" consistent > > - Remove recommendations on use of SDP with SAP from definition of > > "i=3D" since they duplicated RFC 2974 > > - Reference RFC 2822 rather than RFC 822 > > - Clarify that the free-text name associated with email address and > > phone > > number MUST be enclosed in parenthesis, to match the ABNF. > > - Clarify that the X- prefix for bandwidth modifier names is for > > experimental purposes only > > - Rename the top-level construct in the ABNF to "session-description" > > rather than "announcement" > > - Remove duplicate definition of "multimedia session" from section 4 > > - Clarify that the "conventional international format" for phone > > numbers is an E.164 number in section 5.6. Relax (poorly defined) > > requirement for a space or hyphen between the country code and the > > rest of the phone > > number. > > - Clarify which attributes and fields are dependent on charset > > - Better align the ABNF field names and those in the main document > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 18:12:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24503 for ; Fri, 7 May 2004 18:12:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDZ0-0007WN-0j for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 18:11:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47MBPUS028906 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 18:11:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDT2-0003wl-FS for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 18:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23602 for ; Fri, 7 May 2004 18:05:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMDSz-0004wm-PL for mmusic-web-archive@ietf.org; Fri, 07 May 2004 18:05:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDRx-0004Vl-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 18:04:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMDR2-00045v-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 18:03:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDK7-0007UL-7q; Fri, 07 May 2004 17:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMDEX-0005lk-TP for mmusic@optimus.ietf.org; Fri, 07 May 2004 17:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22840 for ; Fri, 7 May 2004 17:50:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMDEV-0006HP-7W for mmusic@ietf.org; Fri, 07 May 2004 17:50:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMDDX-0005rL-00 for mmusic@ietf.org; Fri, 07 May 2004 17:49:16 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BMDCy-0005Q5-00 for mmusic@ietf.org; Fri, 07 May 2004 17:48:40 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 7 May 2004 14:47:50 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 May 2004 14:48:06 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 14:48:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Date: Fri, 7 May 2004 14:48:07 -0700 Message-ID: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt thread-index: AcQ0dV1zFBxLAdgoRxioce3qoWHmpQABX/PAAAB38TA= From: "Orit Levin" To: "Orit Levin" , "Colin Perkins" , "Gonzalo Camarillo" Cc: , "Alan Johnston" , "Rohan Mahy" X-OriginalArrivalTime: 07 May 2004 21:48:08.0759 (UTC) FILETIME=[FC5A6C70:01C4347C] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Correction. The attribute will have the form of "a=3Dl:" . Orit.=20 -----Original Message----- From: Orit Levin=20 Sent: Friday, May 07, 2004 2:37 PM To: 'Colin Perkins'; Gonzalo Camarillo Cc: mmusic@ietf.org; Alan Johnston; Rohan Mahy Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Thanks a lot! So I am continuing with our joint with Gonzalo draft which will define a new label ("l=3D") media attribute being used by automata. I hope that we all agree that there is a need for this attribute in SDP for conferencing and transcoding applications. Orit. -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Friday, May 07, 2004 1:54 PM To: Gonzalo Camarillo Cc: Orit Levin; mmusic@ietf.org; Alan Johnston; Rohan Mahy Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt I agree with Gonzalo - the "i=3D" line is human readable information, = not something that can be processed by automata. Colin On Friday 07 May 2004 20:39, Gonzalo Camarillo wrote: > Orit, > > the intention of the i=3D line is to provide human readable = information. > That is, it is not intended for automata. > > We ran into the same question when designing the grouping stuff and=20 > decided to define the mid attributes for the same reason. > > Regards, > > Gonzalo > > Orit Levin wrote: > > Colin and all, > > In the process of our work on conferencing and other "transcoder" > > applications (in both SIPPING and XCON), we have (re-)identified the > > need for labeling of media streams. I have almost finished writing a > > MMUSIC draft that would introduce "a label" to a media stream when I > > came across the statement below in your draft under the "Session > > Information": > > > > " A single "i=3D" field MAY also be used for each media definition. In > > media definitions, "i=3D" fields are primarily intended for labeling > > media streams. As such, they are most likely to be useful when a > > single session has more than one distinct media stream of the same > > media type. An example would be two different whiteboards, one for > > slides and one for feedback and questions. > > " > > > > Based on this, would you expect that automata will use this=20 > > information or do we still need to add a "label-id" media attributes > > with the semantics similar to "info" but for automata use. > > > > Thanks, > > Orit. > > > > -----Original Message----- > > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf > > Of Colin Perkins > > Sent: Friday, May 07, 2004 1:21 AM > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt > > > > On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts=20 > >>directories. This draft is a work item of the Multiparty Multimedia=20 > >>Session Control Working Group of the IETF. > >> > >> Title : SDP: Session Description Protocol > >> Author(s) : M. Handley, et al. > >> Filename : draft-ietf-mmusic-sdp-new-16.txt > >> Pages : 45 > >> Date : 2004-5-5 > >> > >>This memo defines the Session Description Protocol (SDP). SDP is=20 > >>intended for describing multimedia sessions for the purposes of=20 > >>session announcement, session invitation, and other forms of=20 > >>multimedia session initiation. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt > > > > Changes in this version: > > - Add support for "text" media > > - Add the Macintosh File Type Code to the MIME registration > > - Add IANA registrations for attributes and parameters defined=20 > > herein > > - Delete the definition "session advertisment" from section 2. > > - Make use of the terms "session announcement" and "session=20 > > description" consistent > > - Remove recommendations on use of SDP with SAP from definition of=20 > > "i=3D" since they duplicated RFC 2974 > > - Reference RFC 2822 rather than RFC 822 > > - Clarify that the free-text name associated with email address and=20 > > phone > > number MUST be enclosed in parenthesis, to match the ABNF. > > - Clarify that the X- prefix for bandwidth modifier names is for > > experimental purposes only > > - Rename the top-level construct in the ABNF to "session-description" > > rather than "announcement" > > - Remove duplicate definition of "multimedia session" from section 4 > > - Clarify that the "conventional international format" for phone=20 > > numbers is an E.164 number in section 5.6. Relax (poorly defined)=20 > > requirement for a space or hyphen between the country code and the=20 > > rest of the phone > > number. > > - Clarify which attributes and fields are dependent on charset > > - Better align the ABNF field names and those in the main document > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 19:03:07 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26981 for ; Fri, 7 May 2004 19:03:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEM1-0006fw-Bs for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 19:02:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47N25CJ025655 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 19:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEKC-0006AF-FZ for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 19:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26800 for ; Fri, 7 May 2004 19:00:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMEK9-000563-4x for mmusic-web-archive@ietf.org; Fri, 07 May 2004 19:00:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMEJ7-0004ez-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 18:59:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMEI4-00044E-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 18:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEDG-00048V-Er; Fri, 07 May 2004 18:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BME7b-0002VR-W8 for mmusic@optimus.ietf.org; Fri, 07 May 2004 18:47:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26181 for ; Fri, 7 May 2004 18:47:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BME7Y-0007KK-H3 for mmusic@ietf.org; Fri, 07 May 2004 18:47:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BME6a-0006vD-00 for mmusic@ietf.org; Fri, 07 May 2004 18:46:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BME60-0006FM-00 for mmusic@ietf.org; Fri, 07 May 2004 18:45:32 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 May 2004 15:46:13 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47MirYu011769; Fri, 7 May 2004 18:44:54 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF99788; Fri, 7 May 2004 18:44:54 -0400 (EDT) Message-ID: <409C1166.90905@cisco.com> Date: Fri, 07 May 2004 18:44:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Colin Perkins , Gonzalo Camarillo , mmusic@ietf.org, Alan Johnston , Rohan Mahy Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Could it be at least a *little* more mnemonic and less concise than "l"? Pleeeeease! Paul Orit Levin wrote: > Correction. The attribute will have the form of "a=l:" . > > Orit. > > -----Original Message----- > From: Orit Levin > Sent: Friday, May 07, 2004 2:37 PM > To: 'Colin Perkins'; Gonzalo Camarillo > Cc: mmusic@ietf.org; Alan Johnston; Rohan Mahy > Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt > > Thanks a lot! > > So I am continuing with our joint with Gonzalo draft which will define a > new label ("l=") media attribute being used by automata. > I hope that we all agree that there is a need for this attribute in SDP > for conferencing and transcoding applications. > > Orit. > > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, May 07, 2004 1:54 PM > To: Gonzalo Camarillo > Cc: Orit Levin; mmusic@ietf.org; Alan Johnston; Rohan Mahy > Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt > > I agree with Gonzalo - the "i=" line is human readable information, not > something that can be processed by automata. > Colin > > > > On Friday 07 May 2004 20:39, Gonzalo Camarillo wrote: > >>Orit, >> >>the intention of the i= line is to provide human readable information. >>That is, it is not intended for automata. >> >>We ran into the same question when designing the grouping stuff and >>decided to define the mid attributes for the same reason. >> >>Regards, >> >>Gonzalo >> >>Orit Levin wrote: >> >>>Colin and all, >>>In the process of our work on conferencing and other "transcoder" >>>applications (in both SIPPING and XCON), we have (re-)identified the >> > >>>need for labeling of media streams. I have almost finished writing a >> > >>>MMUSIC draft that would introduce "a label" to a media stream when I >> > >>>came across the statement below in your draft under the "Session >>>Information": >>> >>>" A single "i=" field MAY also be used for each media definition. >> > In > >>> media definitions, "i=" fields are primarily intended for >> > labeling > >>> media streams. As such, they are most likely to be useful when a >>> single session has more than one distinct media stream of the >> > same > >>> media type. An example would be two different whiteboards, one >> > for > >>> slides and one for feedback and questions. >>>" >>> >>>Based on this, would you expect that automata will use this >>>information or do we still need to add a "label-id" media attributes >> > >>>with the semantics similar to "info" but for automata use. >>> >>>Thanks, >>>Orit. >>> >>>-----Original Message----- >>>From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf >> > >>>Of Colin Perkins >>>Sent: Friday, May 07, 2004 1:21 AM >>>To: mmusic@ietf.org >>>Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt >>> >>>On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: >>> >>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>directories. This draft is a work item of the Multiparty Multimedia >>>>Session Control Working Group of the IETF. >>>> >>>> Title : SDP: Session Description Protocol >>>> Author(s) : M. Handley, et al. >>>> Filename : draft-ietf-mmusic-sdp-new-16.txt >>>> Pages : 45 >>>> Date : 2004-5-5 >>>> >>>>This memo defines the Session Description Protocol (SDP). SDP is >>>>intended for describing multimedia sessions for the purposes of >>>>session announcement, session invitation, and other forms of >>>>multimedia session initiation. >>>> >>>>A URL for this Internet-Draft is: >>>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt >>> >>>Changes in this version: >>>- Add support for "text" media >>>- Add the Macintosh File Type Code to the MIME registration >>>- Add IANA registrations for attributes and parameters defined >>>herein >>>- Delete the definition "session advertisment" from section 2. >>>- Make use of the terms "session announcement" and "session >>>description" consistent >>>- Remove recommendations on use of SDP with SAP from definition of >>>"i=" since they duplicated RFC 2974 >>>- Reference RFC 2822 rather than RFC 822 >>>- Clarify that the free-text name associated with email address and >>>phone >>> number MUST be enclosed in parenthesis, to match the ABNF. >>>- Clarify that the X- prefix for bandwidth modifier names is for >>> experimental purposes only >>>- Rename the top-level construct in the ABNF to >> > "session-description" > >>> rather than "announcement" >>>- Remove duplicate definition of "multimedia session" from section 4 >>>- Clarify that the "conventional international format" for phone >>>numbers is an E.164 number in section 5.6. Relax (poorly defined) >>>requirement for a space or hyphen between the country code and the >>>rest of the phone >>> number. >>>- Clarify which attributes and fields are dependent on charset >>>- Better align the ABNF field names and those in the main document >>> >>>-- >>>Colin Perkins >>>http://csperkins.org/ >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> > > -- > Colin Perkins > http://csperkins.org/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 7 19:14:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27712 for ; Fri, 7 May 2004 19:14:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEVX-0001Fh-Qn for mmusic-archive@odin.ietf.org; Fri, 07 May 2004 19:11:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47NBtfW004809 for mmusic-archive@odin.ietf.org; Fri, 7 May 2004 19:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEQA-0007ls-LH for mmusic-web-archive@optimus.ietf.org; Fri, 07 May 2004 19:06:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27207 for ; Fri, 7 May 2004 19:06:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMEQ7-0007mt-6m for mmusic-web-archive@ietf.org; Fri, 07 May 2004 19:06:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMEP5-0007MT-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 19:05:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMEOS-0006wd-00 for mmusic-web-archive@ietf.org; Fri, 07 May 2004 19:04:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEMv-0006wd-J7; Fri, 07 May 2004 19:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMEKK-0006AS-IQ for mmusic@optimus.ietf.org; Fri, 07 May 2004 19:00:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26829 for ; Fri, 7 May 2004 19:00:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMEKH-000572-87 for mmusic@ietf.org; Fri, 07 May 2004 19:00:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMEJI-0004gN-00 for mmusic@ietf.org; Fri, 07 May 2004 18:59:17 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1BMEIo-0004G5-00 for mmusic@ietf.org; Fri, 07 May 2004 18:58:46 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 7 May 2004 15:57:54 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 May 2004 15:58:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 15:58:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Date: Fri, 7 May 2004 15:58:14 -0700 Message-ID: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt thread-index: AcQ0hO9jnc0llpHpR+eZWQiPQjMlrgAAad5A From: "Orit Levin" To: "Paul Kyzivat" Cc: "Colin Perkins" , "Gonzalo Camarillo" , , "Alan Johnston" , "Rohan Mahy" X-OriginalArrivalTime: 07 May 2004 22:58:15.0645 (UTC) FILETIME=[C7DA48D0:01C43486] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sure! "a=3Dlabel:" ? Orit. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, May 07, 2004 3:45 PM To: Orit Levin Cc: Colin Perkins; Gonzalo Camarillo; mmusic@ietf.org; Alan Johnston; Rohan Mahy Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt Could it be at least a *little* more mnemonic and less concise than "l"? Pleeeeease! Paul Orit Levin wrote: > Correction. The attribute will have the form of "a=3Dl:" . >=20 > Orit.=20 >=20 > -----Original Message----- > From: Orit Levin > Sent: Friday, May 07, 2004 2:37 PM > To: 'Colin Perkins'; Gonzalo Camarillo > Cc: mmusic@ietf.org; Alan Johnston; Rohan Mahy > Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt >=20 > Thanks a lot! >=20 > So I am continuing with our joint with Gonzalo draft which will define > a new label ("l=3D") media attribute being used by automata. > I hope that we all agree that there is a need for this attribute in=20 > SDP for conferencing and transcoding applications. >=20 > Orit. >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, May 07, 2004 1:54 PM > To: Gonzalo Camarillo > Cc: Orit Levin; mmusic@ietf.org; Alan Johnston; Rohan Mahy > Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt >=20 > I agree with Gonzalo - the "i=3D" line is human readable information,=20 > not something that can be processed by automata. > Colin >=20 >=20 >=20 > On Friday 07 May 2004 20:39, Gonzalo Camarillo wrote: >=20 >>Orit, >> >>the intention of the i=3D line is to provide human readable = information. >>That is, it is not intended for automata. >> >>We ran into the same question when designing the grouping stuff and=20 >>decided to define the mid attributes for the same reason. >> >>Regards, >> >>Gonzalo >> >>Orit Levin wrote: >> >>>Colin and all, >>>In the process of our work on conferencing and other "transcoder" >>>applications (in both SIPPING and XCON), we have (re-)identified the >> >=20 >>>need for labeling of media streams. I have almost finished writing a >> >=20 >>>MMUSIC draft that would introduce "a label" to a media stream when I >> >=20 >>>came across the statement below in your draft under the "Session >>>Information": >>> >>>" A single "i=3D" field MAY also be used for each media definition. >> > In >=20 >>> media definitions, "i=3D" fields are primarily intended for >> > labeling >=20 >>> media streams. As such, they are most likely to be useful when a >>> single session has more than one distinct media stream of the >> > same >=20 >>> media type. An example would be two different whiteboards, one >> > for >=20 >>> slides and one for feedback and questions. >>>" >>> >>>Based on this, would you expect that automata will use this=20 >>>information or do we still need to add a "label-id" media attributes >> >=20 >>>with the semantics similar to "info" but for automata use. >>> >>>Thanks, >>>Orit. >>> >>>-----Original Message----- >>>From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf >> >=20 >>>Of Colin Perkins >>>Sent: Friday, May 07, 2004 1:21 AM >>>To: mmusic@ietf.org >>>Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt >>> >>>On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: >>> >>>>A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>>directories. This draft is a work item of the Multiparty Multimedia=20 >>>>Session Control Working Group of the IETF. >>>> >>>> Title : SDP: Session Description Protocol >>>> Author(s) : M. Handley, et al. >>>> Filename : draft-ietf-mmusic-sdp-new-16.txt >>>> Pages : 45 >>>> Date : 2004-5-5 >>>> >>>>This memo defines the Session Description Protocol (SDP). SDP is=20 >>>>intended for describing multimedia sessions for the purposes of=20 >>>>session announcement, session invitation, and other forms of=20 >>>>multimedia session initiation. >>>> >>>>A URL for this Internet-Draft is: >>>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt >>> >>>Changes in this version: >>>- Add support for "text" media >>>- Add the Macintosh File Type Code to the MIME registration >>>- Add IANA registrations for attributes and parameters defined herein >>>- Delete the definition "session advertisment" from section 2. >>>- Make use of the terms "session announcement" and "session=20 >>>description" consistent >>>- Remove recommendations on use of SDP with SAP from definition of=20 >>>"i=3D" since they duplicated RFC 2974 >>>- Reference RFC 2822 rather than RFC 822 >>>- Clarify that the free-text name associated with email address and=20 >>>phone >>> number MUST be enclosed in parenthesis, to match the ABNF. >>>- Clarify that the X- prefix for bandwidth modifier names is for >>> experimental purposes only >>>- Rename the top-level construct in the ABNF to >> > "session-description" >=20 >>> rather than "announcement" >>>- Remove duplicate definition of "multimedia session" from section 4 >>>- Clarify that the "conventional international format" for phone=20 >>>numbers is an E.164 number in section 5.6. Relax (poorly defined)=20 >>>requirement for a space or hyphen between the country code and the=20 >>>rest of the phone >>> number. >>>- Clarify which attributes and fields are dependent on charset >>>- Better align the ABNF field names and those in the main document >>> >>>-- >>>Colin Perkins >>>http://csperkins.org/ >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >> >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun May 9 11:12:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08111 for ; Sun, 9 May 2004 11:12:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMpy9-00006Y-Tj for mmusic-archive@odin.ietf.org; Sun, 09 May 2004 11:11:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i49FBvok000402 for mmusic-archive@odin.ietf.org; Sun, 9 May 2004 11:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMpx3-0008Ry-TM for mmusic-web-archive@optimus.ietf.org; Sun, 09 May 2004 11:10:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08007 for ; Sun, 9 May 2004 11:10:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMpx1-0004UR-9x for mmusic-web-archive@ietf.org; Sun, 09 May 2004 11:10:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMpw7-0004BF-00 for mmusic-web-archive@ietf.org; Sun, 09 May 2004 11:09:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMpvF-0003sq-00 for mmusic-web-archive@ietf.org; Sun, 09 May 2004 11:08:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMppV-0007Sd-0Q; Sun, 09 May 2004 11:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMpoL-0007Nd-UP for mmusic@optimus.ietf.org; Sun, 09 May 2004 11:01:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07771 for ; Sun, 9 May 2004 11:01:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMpoJ-0001kS-DR for mmusic@ietf.org; Sun, 09 May 2004 11:01:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMpnV-0001Ri-00 for mmusic@ietf.org; Sun, 09 May 2004 11:00:58 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BMpma-0000oG-00 for mmusic@ietf.org; Sun, 09 May 2004 11:00:00 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63386 helo=[192.168.0.3]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BMpm5-00009c-00 for mmusic@ietf.org; Sun, 09 May 2004 15:59:29 +0100 From: Colin Perkins Organization: http://csperkins.org To: mmusic@ietf.org Date: Sun, 9 May 2004 15:59:27 +0100 User-Agent: KMail/1.6.2 References: <200405061533.LAA20435@ietf.org> In-Reply-To: <200405061533.LAA20435@ietf.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405091559.27719.csp@csperkins.org> Content-Transfer-Encoding: 7bit Subject: [MMUSIC] WG last call: draft-ietf-mmusic-sdescriptions-04.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is to announce a two-week working group last call on the SDP Security Descriptions for Media Streams (draft-ietf-mmusic-sdescriptions-04.txt). Please send any final comments on this draft to the mailing list by 21st May 2004. If no substantive comments are received by that time, we shall request the IESG consider this for publication as a Proposed Standard RFC. The following technical changes have occurred since the previous version of this draft, necessitating another working group last call: 1) Addition of a new FEC_KEY parameter to specify key(s) for a FEC stream that is separate from the media stream itself (new Section 5.3.5, updated grammar, and updated SRTP offer/answer rules as a result). 2) Removal of the "SPLIT" FEC mode parameter 3) Addition of text to deal with changing IP-address and/or port when updating the session (Section 6.1.4). 4) Removed support for SRTP-specific use of sdescriptions outside offer/answer (Section 6.2) as it had a problem with RTCP support. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon May 10 08:01:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27672 for ; Mon, 10 May 2004 08:01:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9RL-0002Zg-2K for mmusic-archive@odin.ietf.org; Mon, 10 May 2004 07:59:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ABxN2C009896 for mmusic-archive@odin.ietf.org; Mon, 10 May 2004 07:59:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9Nt-00023K-8f for mmusic-web-archive@optimus.ietf.org; Mon, 10 May 2004 07:55:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27375 for ; Mon, 10 May 2004 07:55:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9Ns-0002L0-Er for mmusic-web-archive@ietf.org; Mon, 10 May 2004 07:55:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9Mn-000200-00 for mmusic-web-archive@ietf.org; Mon, 10 May 2004 07:54:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN9Lz-0001hy-00 for mmusic-web-archive@ietf.org; Mon, 10 May 2004 07:53:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9FN-00018u-Ht; Mon, 10 May 2004 07:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9E9-000123-Pq for mmusic@optimus.ietf.org; Mon, 10 May 2004 07:45:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26967 for ; Mon, 10 May 2004 07:45:43 -0400 (EDT) From: marco.stura@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9E8-00073I-VZ for mmusic@ietf.org; Mon, 10 May 2004 07:45:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9DL-0006lD-00 for mmusic@ietf.org; Mon, 10 May 2004 07:44:56 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BN9Cc-0006SV-00 for mmusic@ietf.org; Mon, 10 May 2004 07:44:10 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4ABi8H29511 for ; Mon, 10 May 2004 14:44:08 +0300 (EET DST) X-Scanned: Mon, 10 May 2004 14:44:05 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4ABi5jO004992 for ; Mon, 10 May 2004 14:44:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00xWTlCY; Mon, 10 May 2004 14:44:02 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4ABi1H21323 for ; Mon, 10 May 2004 14:44:01 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 May 2004 14:42:32 +0300 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: Mon, 10 May 2004 14:42:32 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0540@esebe016.ntc.nokia.com> Thread-Topic: question on comedia draft status Thread-Index: AcQ2g+HDvWKgKmFMQBaeGR25enGHfQ== To: X-OriginalArrivalTime: 10 May 2004 11:42:32.0313 (UTC) FILETIME=[E1620690:01C43683] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] question on comedia draft status Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I was looking in to the comedia draft to evaluate its applicability to = enable the traversal of media streams through NAT devices and found that it expired on March 2003. I was then wondering what is the actual status of this draft since it = appears to still be an official working group item. Could someone clarify? Thank you Marco _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon May 10 08:02:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27711 for ; Mon, 10 May 2004 08:02:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9Sm-0002jP-JD for mmusic-archive@odin.ietf.org; Mon, 10 May 2004 08:00:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AC0q2w010494 for mmusic-archive@odin.ietf.org; Mon, 10 May 2004 08:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9Qu-0002Mp-Bg for mmusic-web-archive@optimus.ietf.org; Mon, 10 May 2004 07:58:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27568 for ; Mon, 10 May 2004 07:58:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9Qt-0003Kf-Hg for mmusic-web-archive@ietf.org; Mon, 10 May 2004 07:58:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9Pz-00031n-00 for mmusic-web-archive@ietf.org; Mon, 10 May 2004 07:57:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN9PE-0002iE-00 for mmusic-web-archive@ietf.org; Mon, 10 May 2004 07:57:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9KC-0001Uf-Sy; Mon, 10 May 2004 07:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9F2-00017E-Gu for mmusic@optimus.ietf.org; Mon, 10 May 2004 07:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27117 for ; Mon, 10 May 2004 07:46:38 -0400 (EDT) From: marco.stura@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9F1-0007O2-Lw for mmusic@ietf.org; Mon, 10 May 2004 07:46:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9E3-00072a-00 for mmusic@ietf.org; Mon, 10 May 2004 07:45:39 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BN9D4-0006jW-00 for mmusic@ietf.org; Mon, 10 May 2004 07:44:39 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4ABibv02466 for ; Mon, 10 May 2004 14:44:37 +0300 (EET DST) X-Scanned: Mon, 10 May 2004 14:44:33 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4ABiX2t006462 for ; Mon, 10 May 2004 14:44:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 002Gnx7p; Mon, 10 May 2004 14:44:32 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4ABiUH21799 for ; Mon, 10 May 2004 14:44:30 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 May 2004 14:44:15 +0300 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: Mon, 10 May 2004 14:44:15 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C8738@esebe016.ntc.nokia.com> Thread-Topic: question on comedia draft status Thread-Index: AcQ2g+HDvWKgKmFMQBaeGR25enGHfQAAA+sw To: X-OriginalArrivalTime: 10 May 2004 11:44:15.0968 (UTC) FILETIME=[1F2A8600:01C43684] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] FW: question on comedia draft status Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ops...it has expired on September 2003. > -----Original Message----- > From: Stura Marco (Nokia-NET/Helsinki) =20 > Sent: 10 May, 2004 14:43 > To: 'mmusic@ietf.org' > Subject: question on comedia draft status >=20 > Hi, >=20 > I was looking in to the comedia draft to evaluate its=20 > applicability to enable the traversal of media > streams through NAT devices and found that it expired on March 2003. >=20 > I was then wondering what is the actual status of this draft=20 > since it appears to still be an official > working group item. Could someone clarify? >=20 > Thank you > Marco >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon May 10 09:09:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01708 for ; Mon, 10 May 2004 09:09:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAKM-00048x-ES for mmusic-archive@odin.ietf.org; Mon, 10 May 2004 08:56:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ACuEuf015922 for mmusic-archive@odin.ietf.org; Mon, 10 May 2004 08:56:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNABS-0002O1-W1 for mmusic-web-archive@optimus.ietf.org; Mon, 10 May 2004 08:47:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00292 for ; Mon, 10 May 2004 08:47:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNABR-0003Ih-MP for mmusic-web-archive@ietf.org; Mon, 10 May 2004 08:47:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNAAa-0002wY-00 for mmusic-web-archive@ietf.org; Mon, 10 May 2004 08:46:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNA9b-0002ah-00 for mmusic-web-archive@ietf.org; Mon, 10 May 2004 08:45:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9t3-0005nH-Ba; Mon, 10 May 2004 08:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN9m6-00054Y-3P for mmusic@optimus.ietf.org; Mon, 10 May 2004 08:20:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28596 for ; Mon, 10 May 2004 08:20:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN9m4-0002ML-VT for mmusic@ietf.org; Mon, 10 May 2004 08:20:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN9ky-00020l-00 for mmusic@ietf.org; Mon, 10 May 2004 08:19:40 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BN9js-0001P3-00 for mmusic@ietf.org; Mon, 10 May 2004 08:18:32 -0400 Received: from mangole ([130.209.247.112]:63580) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BN9jN-0003KF-00; Mon, 10 May 2004 13:18:01 +0100 From: Colin Perkins Organization: http://csperkins.org To: mmusic@ietf.org Subject: Re: [MMUSIC] question on comedia draft status Date: Mon, 10 May 2004 13:17:59 +0100 User-Agent: KMail/1.6.2 Cc: marco.stura@nokia.com References: <142DC466081D9B409AAD1DDCA4B21E1D018B0540@esebe016.ntc.nokia.com> In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D018B0540@esebe016.ntc.nokia.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405101318.00069.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday 10 May 2004 12:42, marco.stura@nokia.com wrote: > I was looking in to the comedia draft to evaluate its applicability to > enable the traversal of media streams through NAT devices and found that > it expired on March 2003. > > I was then wondering what is the actual status of this draft since it > appears to still be an official working group item. Could someone > clarify? There is ongoing discussion about producing a new version. Likely there will be an update in the next few weeks. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon May 10 09:32:35 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02846 for ; Mon, 10 May 2004 09:32:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAsA-0003SN-Di for mmusic-archive@odin.ietf.org; Mon, 10 May 2004 09:31:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ADVAij013288 for mmusic-archive@odin.ietf.org; Mon, 10 May 2004 09:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNApt-0002ky-UZ for mmusic-web-archive@optimus.ietf.org; Mon, 10 May 2004 09:28:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02737 for ; Mon, 10 May 2004 09:28:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNAps-0001UD-9b for mmusic-web-archive@ietf.org; Mon, 10 May 2004 09:28:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNAov-0001Ba-00 for mmusic-web-archive@ietf.org; Mon, 10 May 2004 09:27:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNAoV-0000tM-00 for mmusic-web-archive@ietf.org; Mon, 10 May 2004 09:27:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAeS-0001Xk-K6; Mon, 10 May 2004 09:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNAba-0001CM-Sl for mmusic@optimus.ietf.org; Mon, 10 May 2004 09:14:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02171 for ; Mon, 10 May 2004 09:13:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNAbZ-0004aw-B9 for mmusic@ietf.org; Mon, 10 May 2004 09:14:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNAaf-0004FY-00 for mmusic@ietf.org; Mon, 10 May 2004 09:13:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BNAZl-0003l8-00 for mmusic@ietf.org; Mon, 10 May 2004 09:12:09 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 10 May 2004 06:12:08 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4ADBTpK026281; Mon, 10 May 2004 09:11:30 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIG57559; Mon, 10 May 2004 09:11:29 -0400 (EDT) Message-ID: <409F7F83.6080404@cisco.com> Date: Mon, 10 May 2004 09:11:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Colin Perkins , Gonzalo Camarillo , mmusic@ietf.org, Alan Johnston , Rohan Mahy Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit, Thanks. Seriously - that *is* much better. Paul Orit Levin wrote: > Sure! "a=label:" ? > > Orit. > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, May 07, 2004 3:45 PM > To: Orit Levin > Cc: Colin Perkins; Gonzalo Camarillo; mmusic@ietf.org; Alan Johnston; > Rohan Mahy > Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt > > Could it be at least a *little* more mnemonic and less concise than "l"? > > Pleeeeease! > > Paul > > Orit Levin wrote: > >>Correction. The attribute will have the form of "a=l:" . >> >>Orit. >> >>-----Original Message----- >>From: Orit Levin >>Sent: Friday, May 07, 2004 2:37 PM >>To: 'Colin Perkins'; Gonzalo Camarillo >>Cc: mmusic@ietf.org; Alan Johnston; Rohan Mahy >>Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt >> >>Thanks a lot! >> >>So I am continuing with our joint with Gonzalo draft which will define > > >>a new label ("l=") media attribute being used by automata. >>I hope that we all agree that there is a need for this attribute in >>SDP for conferencing and transcoding applications. >> >>Orit. >> >>-----Original Message----- >>From: Colin Perkins [mailto:csp@csperkins.org] >>Sent: Friday, May 07, 2004 1:54 PM >>To: Gonzalo Camarillo >>Cc: Orit Levin; mmusic@ietf.org; Alan Johnston; Rohan Mahy >>Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt >> >>I agree with Gonzalo - the "i=" line is human readable information, >>not something that can be processed by automata. >>Colin >> >> >> >>On Friday 07 May 2004 20:39, Gonzalo Camarillo wrote: >> >> >>>Orit, >>> >>>the intention of the i= line is to provide human readable information. >>>That is, it is not intended for automata. >>> >>>We ran into the same question when designing the grouping stuff and >>>decided to define the mid attributes for the same reason. >>> >>>Regards, >>> >>>Gonzalo >>> >>>Orit Levin wrote: >>> >>> >>>>Colin and all, >>>>In the process of our work on conferencing and other "transcoder" >>>>applications (in both SIPPING and XCON), we have (re-)identified the >>> >>>>need for labeling of media streams. I have almost finished writing a >>> >>>>MMUSIC draft that would introduce "a label" to a media stream when I >>> >>>>came across the statement below in your draft under the "Session >>>>Information": >>>> >>>>" A single "i=" field MAY also be used for each media definition. >>> >>In >> >> >>>> media definitions, "i=" fields are primarily intended for >>> >>labeling >> >> >>>> media streams. As such, they are most likely to be useful when a >>>> single session has more than one distinct media stream of the >>> >>same >> >> >>>> media type. An example would be two different whiteboards, one >>> >>for >> >> >>>> slides and one for feedback and questions. >>>>" >>>> >>>>Based on this, would you expect that automata will use this >>>>information or do we still need to add a "label-id" media attributes >>> >>>>with the semantics similar to "info" but for automata use. >>>> >>>>Thanks, >>>>Orit. >>>> >>>>-----Original Message----- >>>>From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf >>> >>>>Of Colin Perkins >>>>Sent: Friday, May 07, 2004 1:21 AM >>>>To: mmusic@ietf.org >>>>Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-16.txt >>>> >>>>On Thursday 06 May 2004 16:32, Internet-Drafts@ietf.org wrote: >>>> >>>> >>>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>>directories. This draft is a work item of the Multiparty Multimedia >>>>>Session Control Working Group of the IETF. >>>>> >>>>> Title : SDP: Session Description Protocol >>>>> Author(s) : M. Handley, et al. >>>>> Filename : draft-ietf-mmusic-sdp-new-16.txt >>>>> Pages : 45 >>>>> Date : 2004-5-5 >>>>> >>>>>This memo defines the Session Description Protocol (SDP). SDP is >>>>>intended for describing multimedia sessions for the purposes of >>>>>session announcement, session invitation, and other forms of >>>>>multimedia session initiation. >>>>> >>>>>A URL for this Internet-Draft is: >>>>>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt >>>> >>>>Changes in this version: >>>>- Add support for "text" media >>>>- Add the Macintosh File Type Code to the MIME registration >>>>- Add IANA registrations for attributes and parameters defined herein >>>>- Delete the definition "session advertisment" from section 2. >>>>- Make use of the terms "session announcement" and "session >>>>description" consistent >>>>- Remove recommendations on use of SDP with SAP from definition of >>>>"i=" since they duplicated RFC 2974 >>>>- Reference RFC 2822 rather than RFC 822 >>>>- Clarify that the free-text name associated with email address and >>>>phone >>>> number MUST be enclosed in parenthesis, to match the ABNF. >>>>- Clarify that the X- prefix for bandwidth modifier names is for >>>> experimental purposes only >>>>- Rename the top-level construct in the ABNF to >>> >>"session-description" >> >> >>>> rather than "announcement" >>>>- Remove duplicate definition of "multimedia session" from section 4 >>>>- Clarify that the "conventional international format" for phone >>>>numbers is an E.164 number in section 5.6. Relax (poorly defined) >>>>requirement for a space or hyphen between the country code and the >>>>rest of the phone >>>> number. >>>>- Clarify which attributes and fields are dependent on charset >>>>- Better align the ABNF field names and those in the main document >>>> >>>>-- >>>>Colin Perkins >>>>http://csperkins.org/ >>>> >>>>_______________________________________________ >>>>mmusic mailing list >>>>mmusic@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >>-- >>Colin Perkins >>http://csperkins.org/ >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue May 11 09:23:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24972 for ; Tue, 11 May 2004 09:23:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNXA9-0002Mp-Jc for mmusic-archive@odin.ietf.org; Tue, 11 May 2004 09:19:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BDJDXY009099 for mmusic-archive@odin.ietf.org; Tue, 11 May 2004 09:19:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNX4w-0001GP-C1 for mmusic-web-archive@optimus.ietf.org; Tue, 11 May 2004 09:13:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24504 for ; Tue, 11 May 2004 09:13:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNX4u-0006A0-UU for mmusic-web-archive@ietf.org; Tue, 11 May 2004 09:13:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNX3w-0005jQ-00 for mmusic-web-archive@ietf.org; Tue, 11 May 2004 09:12:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNX2o-00054i-00 for mmusic-web-archive@ietf.org; Tue, 11 May 2004 09:11:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWwZ-0007zb-It; Tue, 11 May 2004 09:05:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNWof-0006CA-IV for mmusic@optimus.ietf.org; Tue, 11 May 2004 08:57:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23842 for ; Tue, 11 May 2004 08:56:58 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNWoe-0007HU-0C for mmusic@ietf.org; Tue, 11 May 2004 08:57:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNWnr-0006qh-00 for mmusic@ietf.org; Tue, 11 May 2004 08:56:12 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BNWmW-00063C-00 for mmusic@ietf.org; Tue, 11 May 2004 08:54:48 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4BCsfk23392; Tue, 11 May 2004 15:54:41 +0300 (EET DST) X-Scanned: Tue, 11 May 2004 15:54:35 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i4BCsZ1f027820; Tue, 11 May 2004 15:54:35 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00lut7qn; Tue, 11 May 2004 15:54:34 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4BCsXH09630; Tue, 11 May 2004 15:54:33 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 15:54:22 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 15:54:22 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe022.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 15:54:22 +0300 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 Subject: RE: [MMUSIC] SDP Session Description for FLUTE Sessions Date: Tue, 11 May 2004 15:54:21 +0300 Message-ID: Thread-Topic: [MMUSIC] SDP Session Description for FLUTE Sessions Thread-Index: AcQ0UGXeGLCLPMy6S7u2uPfwqf9FpAC5t9Bg To: Cc: X-OriginalArrivalTime: 11 May 2004 12:54:22.0662 (UTC) FILETIME=[14F6D660:01C43757] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Steve Yes, that's the critical point. It boils down to whether m=3Dapplication = and the careful use (and registry) of the is sufficient to = select the right application. If not, then m=3Dvideo, etc, would be = required. If so then we have the option to only use m=3Dapplication. I has to be said that an obvious group of FLUTE applications are those = which don't consume the data at all and are just instructed to get all, = or criteria-matching, files from a FLUTE session. These "applications" = do not need or want to know about "application selection" and, more = importantly, may not be the only kind of application on the receiving = end of the session (some clients may be interested only in video clips, = others are "crawling" to get everything). So there is a clear (and not = exclusive) case where SDP would be primarily responsible for providing = session parameters, but not so much the application selection. A quick look at... http://www.iana.org/assignments/media-types/index.html ...reveals that whatever path we go down some registration of subtypes = is necessary. My main concern is that most of the multimedia types are = registered as video and audio subtypes and not under application. So a = serious, non-technical issue, is the invisible barrier of having to = register many subtypes under application if application is all we use. = The result would be that mostly "null" ("-"?) would be given and some = "higher process" of service/media discovery would prepare the client = with details of which application to choose for the "application-less" = SDP (and IANA registration would be an orthogonal issue, time wise). = (I'm happy with that, but I'm more pragmatic than perfect :) Although I want an easy and simple solution (i.e. kill as many options = as possible), I'm not convinced that disallowing other-than-application = media type makes sense (unless it's to get rapid agreement). So I propose that an I-D specifying "SDP for FLUTE" will say this: " SDP [] and IANA [] specify several media types which may be used in the = media field(s) of an SDP description. It is generally RECOMMENDED to use = the "application" media type for FLUTE [] media ("m=3Dapplication..."). The Further Media Type (fmt) list of the SDP media field is used to = describe media subtypes and thus may be used to select an appropriate = application with which to receive the FLUTE session (in the case of = applications which are specialised to certain content types and include = FLUTE reception capabilities). The list may include, or consist entirely = of, a single null subtype, represented by "-" (without the quotes). This = serves the purpose of indicating that some other means is assumed of = selecting the FLUTE application for reception, for some or all the files = of a FLUTE session. Examples of another means include interrogating the = FDT (File Description Table) Instance(s) of the FLUTE session and an = alternative service description, as part of a service/media discovery = framework, that would describe the content types. [Ed. this new "-" = subtype could/should be IANA registered and selection of "-", "null", = "0" needs consensus] To avoid placing limitations on the selection of any congestion control = (CC) building block (BB) [] used with FLUTE, it is STRONGLY RECOMMENDED = to use the same media type and fmt list for all media of a FLUTE = session. An exception to this could be if the CC BB where to channelise = the FLUTE session according to file type. [Ed. no such CCBB has been = proposed in RMT as far as I am aware] These mechanisms implicitly provide a client with the ability to = evaluate its capability to consume the included content types, and thus = assess whether the session content is not render'able though lack of = application support, potentially enabling pre-fetch of additional = application codecs, and the like. However, archiving unusable files = maybe of use to any caching host where capabilities may be modified at a = later time, or the content may be subsequently forwarded to a capable = host. [Ed. the [] points represent a reference unless given earlier. Also does = fmt mean further media types?] " Cheers, Rod. > -----Original Message----- > From: casner@packetdesign.com=20 > [mailto:casner@packetdesign.com]On Behalf > Of ext Stephen Casner > Sent: Friday, May 07, 2004 7:27 PM > To: Walsh Rod (Nokia-NRC/Tampere) > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] SDP Session Description for FLUTE Sessions >=20 >=20 > On Fri, 7 May 2004 Rod.Walsh@nokia.com wrote: >=20 > > > From: ext Colin Perkins [mailto:csp@csperkins.org] > > > I think that sometimes allowing a MIME content type, and sometimes > > > using "m=3Ddata" will be very confusing. We should have a single > > > definition, if possible. > > > > It boils down to what is needed to configure the FLUTE receiver > > application. For mixed content FLUTE receivers a we need to have > > "content is mixed or unspecified" description (either "m=3Ddata" or > > "m=3Dapplication" with null fmt would do the job. For single content > > session receivers (e.g. a video player) we could allow multiple > > media types which may simplify receiver operation but does > > complicate (confuse) the SDP. I think this would be fine to only > > allow "mixed content" media type. > > > > Is anyone unhappy if we only allow "mixed content" media type (in > > the m=3D"media type") and disallow specifics (audio, video, ...)? >=20 > Well, the original design and application of SDP in the MBone was to > allow selection of the right application to receive an advertised > stream. Mark Handley has made this point on numerous occasions in the > past. There is a distinction between the information needed to select > the right receiving application, and then the details that the > application needs to configure itself. We get into trouble because > that boundary is not always clear, or not the same over the space of > all applications. >=20 > To answer specifically for FLUTE, is it likely that there will be > different applications to be invoked for receiving video via FLUTE > versus, say, file download? My guess is the answer would be yes. So, > unless the expected design for FLUTE applications is that there would > be some front end that is required to be able to receive (or at least > consider receiving) anything, and it is responsible for dispatching to > another level, I think we need to make a distinction at the SDP level. >=20 > In particular, if there is a video simulcast with multiple > transmission methods, one of which is FLUTE and the other is some > other protocol, and I have a FLUTE file download receiver on my box > but no capability to receive video via FLUTE, I might not be able to > make an informed decision about which of the simulcast streams to > choose. >=20 > -- Steve >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 04:22:53 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06489 for ; Fri, 14 May 2004 04:22:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXwf-0002na-Nh for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 04:21:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E8LTRW010758 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 04:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXqE-00018T-Vs for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 04:14:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05952 for ; Fri, 14 May 2004 04:14:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXqC-00027d-9o for mmusic-web-archive@ietf.org; Fri, 14 May 2004 04:14:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXpD-0001aP-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 04:13:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOXoE-0000uj-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 04:12:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXla-0008O3-D4; Fri, 14 May 2004 04:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOXge-00071i-6a for mmusic@optimus.ietf.org; Fri, 14 May 2004 04:04:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05483 for ; Fri, 14 May 2004 04:04:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOXgb-0004Xn-GP for mmusic@ietf.org; Fri, 14 May 2004 04:04:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOXfd-00041j-00 for mmusic@ietf.org; Fri, 14 May 2004 04:03:54 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BOXeX-00031K-00 for mmusic@ietf.org; Fri, 14 May 2004 04:02:45 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4E82ELc027106 for ; Fri, 14 May 2004 03:02:14 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.196]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLP7FJ; Fri, 14 May 2004 03:01:49 -0500 Message-ID: <40A47D07.4050807@ericsson.com> Date: Fri, 14 May 2004 11:02:15 +0300 X-Sybari-Trust: 5dcb557b 08d63d2e 09a997dd 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comedia draft Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we have just submitted a new version of the comedia draft. Until it appears in the archives, you can fetch it from: http://standards.ericsson.net/gonzalo/papers/draft-ietf-mmusic-sdp-comedia-06.txt We have simplified the draft and removed stuff that has been addressed by other documents which appeared after version 05 of comedia was written. This is an important piece still missing in SDP, so we would encourage people to provide feedback so that we can move this forward reasonable quickly. Comments are very welcome. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 05:24:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09114 for ; Fri, 14 May 2004 05:24:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYos-0000lc-Ub for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 05:17:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E9HUQL002943 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 05:17:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYlP-0008UO-Jd for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 05:13:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08872 for ; Fri, 14 May 2004 05:13:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOYlM-00014q-Ah for mmusic-web-archive@ietf.org; Fri, 14 May 2004 05:13:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOYkI-0000Zt-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 05:12:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOYj6-0007V4-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 05:11:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYds-0006dH-7k; Fri, 14 May 2004 05:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYYs-0005XM-8o for mmusic@optimus.ietf.org; Fri, 14 May 2004 05:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08485 for ; Fri, 14 May 2004 05:00:54 -0400 (EDT) From: marco.stura@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOYYp-0002TF-2a for mmusic@ietf.org; Fri, 14 May 2004 05:00:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOYXp-0001vj-00 for mmusic@ietf.org; Fri, 14 May 2004 04:59:54 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BOYWy-0001PY-00 for mmusic@ietf.org; Fri, 14 May 2004 04:59:00 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4E8wxB07181; Fri, 14 May 2004 11:58:59 +0300 (EET DST) X-Scanned: Fri, 14 May 2004 11:58:45 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4E8wjhb004454; Fri, 14 May 2004 11:58:45 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00LGITD0; Fri, 14 May 2004 11:58:44 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4E8whH02654; Fri, 14 May 2004 11:58:43 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 May 2004 11:58:29 +0300 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 Subject: RE: [MMUSIC] Comedia draft Date: Fri, 14 May 2004 11:58:29 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B054E@esebe016.ntc.nokia.com> Thread-Topic: [MMUSIC] Comedia draft Thread-Index: AcQ5i7Opk8tXxPofQ9mFrogIurjCnAABUFPw To: Cc: X-OriginalArrivalTime: 14 May 2004 08:58:29.0445 (UTC) FILETIME=[A03A8F50:01C43991] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Gonzalo, > we have just submitted a new version of the comedia draft. in the previous draft there was a section indicating how to treat UDP = and RTP/AVP like connection oriented media (symmetric RTP). In the new = version this section is not present anymore, why? Is there any other document=20 describing "symmetric RTP"? Regards Marco _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 05:59:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10647 for ; Fri, 14 May 2004 05:59:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZR3-0000I4-EQ for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 05:56:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E9uvSe001116 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 05:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZOB-0008Au-HW for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 05:53:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10332 for ; Fri, 14 May 2004 05:53:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZO7-0005KN-UP for mmusic-web-archive@ietf.org; Fri, 14 May 2004 05:53:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZN3-0004px-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 05:52:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOZMa-0004Mj-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 05:52:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZDg-0005no-9p; Fri, 14 May 2004 05:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZBV-0005Ok-8v for mmusic@optimus.ietf.org; Fri, 14 May 2004 05:40:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09674 for ; Fri, 14 May 2004 05:40:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZBR-0006aw-Ow for mmusic@ietf.org; Fri, 14 May 2004 05:40:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZAX-000673-00 for mmusic@ietf.org; Fri, 14 May 2004 05:39:54 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BOZ9V-00059Z-00 for mmusic@ietf.org; Fri, 14 May 2004 05:38:49 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4E9cILc007412; Fri, 14 May 2004 04:38:18 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.196]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLP0DR; Fri, 14 May 2004 04:37:53 -0500 Message-ID: <40A4938B.2040104@ericsson.com> Date: Fri, 14 May 2004 12:38:19 +0300 X-Sybari-Trust: 46cdcac3 08d63d2e 09a997dd 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marco.stura@nokia.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] Comedia draft References: <142DC466081D9B409AAD1DDCA4B21E1D018B054E@esebe016.ntc.nokia.com> In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D018B054E@esebe016.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Marco, > in the previous draft there was a section indicating how to treat UDP and > RTP/AVP like connection oriented media (symmetric RTP). In the new version > this section is not present anymore, why? Is there any other document > describing "symmetric RTP"? Yes, section 4.6 of comedia-05 used to describe what you point out. I have removed that section from the draft because I believe it is out of the scope of the comedia draft. I want the comedia draft to specify how to describe connection oriented streams in SDP. Explaining how to make RTP streams traverse NATs should be dealt with in a different document. That much said, the ICE framework provides a way to traverse NATs which is much better than the one described in comedia-05. In any event, if there is still interest to document the latter approach, we can discuss where to do it. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 06:33:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12828 for ; Fri, 14 May 2004 06:33:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZx9-0008TM-N8 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:30:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EAU7D6032567 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZvJ-00080n-9o for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 06:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12464 for ; Fri, 14 May 2004 06:28:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZvF-0000IU-FT for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:28:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZty-0007Ed-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:26:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOZse-0006Oo-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:25:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZqI-0006lx-7h; Fri, 14 May 2004 06:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZlV-0005kI-FP for mmusic@optimus.ietf.org; Fri, 14 May 2004 06:18:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11832 for ; Fri, 14 May 2004 06:18:01 -0400 (EDT) From: marco.stura@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZlR-0002bN-Km for mmusic@ietf.org; Fri, 14 May 2004 06:18:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZkE-00025V-00 for mmusic@ietf.org; Fri, 14 May 2004 06:16:47 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BOZj4-00016D-00 for mmusic@ietf.org; Fri, 14 May 2004 06:15:34 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EAFSH29564; Fri, 14 May 2004 13:15:28 +0300 (EET DST) X-Scanned: Fri, 14 May 2004 13:15:15 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4EAFFwZ028075; Fri, 14 May 2004 13:15:15 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00XJ1W2b; Fri, 14 May 2004 13:15:13 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EAFCH00542; Fri, 14 May 2004 13:15:12 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 May 2004 13:15:09 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 May 2004 13:15:09 +0300 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 Subject: RE: [MMUSIC] Comedia draft Date: Fri, 14 May 2004 13:15:09 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0550@esebe016.ntc.nokia.com> Thread-Topic: [MMUSIC] Comedia draft Thread-Index: AcQ5l2GXdJKA5+BUTGOqvvDQHGnnlQAANjJQ To: Cc: X-OriginalArrivalTime: 14 May 2004 10:15:09.0693 (UTC) FILETIME=[5630B2D0:01C4399C] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Gonzalo, > I have removed that section from the draft because I believe=20 > it is out=20 > of the scope of the comedia draft. I want the comedia draft=20 > to specify=20 > how to describe connection oriented streams in SDP. Explaining how to=20 > make RTP streams traverse NATs should be dealt with in a=20 > different document. I see your point. However, the symmetric RTP would make use of the setup attribute and all mechanisms defined in comedia draft. Actually=20 the section we are talking about was less than half a page. Does it=20 really make sense to create a different document just for this? > That much said, the ICE framework provides a way to traverse=20 > NATs which=20 > is much better than the one described in comedia-05.=20 What I propose to document is the symetric RTP not a specific discussion = how to traverse NAT with RTP streams. > In any event, if=20 > there is still interest to document the latter approach, we=20 > can discuss=20 > where to do it. At least I'm interested to document the use of symmetric RTP.=20 My preference would be to put back the mentioned section in to the comedia draft, as I see it is relevant to what you describe there. Said that, do you see any other document where to do it? Regards Marco _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 06:44:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13309 for ; Fri, 14 May 2004 06:44:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaA7-00032n-NS for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:43:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EAhV4l011696 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:43:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOa7Y-0002ZL-If for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 06:40:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13152 for ; Fri, 14 May 2004 06:40:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOa7U-0006tC-KP for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:40:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOa6Y-0006Og-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:39:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOa5J-0005Su-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:38:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOa0w-0000uA-Pd; Fri, 14 May 2004 06:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOZzu-0000gc-8k for mmusic@optimus.ietf.org; Fri, 14 May 2004 06:32:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12794 for ; Fri, 14 May 2004 06:32:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOZzq-0002wR-5o for mmusic@ietf.org; Fri, 14 May 2004 06:32:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOZyr-0002RA-00 for mmusic@ietf.org; Fri, 14 May 2004 06:31:54 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1BOZxj-0001Pi-00 for mmusic@ietf.org; Fri, 14 May 2004 06:30:43 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i4EAUBLc012965; Fri, 14 May 2004 05:30:11 -0500 (CDT) Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.196]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQWLQA41; Fri, 14 May 2004 05:29:46 -0500 Message-ID: <40A49FB3.4070401@ericsson.com> Date: Fri, 14 May 2004 13:30:11 +0300 X-Sybari-Trust: e1dae057 08d63d2e 09a997dd 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marco.stura@nokia.com CC: mmusic@ietf.org, Joerg Ott , Colin Perkins Subject: Re: [MMUSIC] Comedia draft References: <142DC466081D9B409AAD1DDCA4B21E1D018B0550@esebe016.ntc.nokia.com> In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D018B0550@esebe016.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Marco, I am cc:ing the chairs for advice on this one. My opinion is that a draft defining symmetric RTP should discuss the advantages of it, which types of NATs can be traversed, which ones cannot be traversed, why an implementer would want to use symmetric RTP instead or in addition to ICE, etc... and all these discussions do not belong to the comedia draft at all. So, I would propose that symmetric RTP is documented in a separate, possibly new, document. Your suggestion of saving one document by defining symmetric RTP in comedia does not seem compeling to me, but I would like to hear the chairs' opinion. I will do what they think it is more appropriate. Thanks, Gonzalo marco.stura@nokia.com wrote: > Gonzalo, > > >>I have removed that section from the draft because I believe >>it is out >>of the scope of the comedia draft. I want the comedia draft >>to specify >>how to describe connection oriented streams in SDP. Explaining how to >>make RTP streams traverse NATs should be dealt with in a >>different document. > > > I see your point. However, the symmetric RTP would make use of the > setup attribute and all mechanisms defined in comedia draft. Actually > the section we are talking about was less than half a page. Does it > really make sense to create a different document just for this? > > >>That much said, the ICE framework provides a way to traverse >>NATs which >>is much better than the one described in comedia-05. > > > What I propose to document is the symetric RTP not a specific discussion > how to traverse NAT with RTP streams. > > >>In any event, if >>there is still interest to document the latter approach, we >>can discuss >>where to do it. > > > At least I'm interested to document the use of symmetric RTP. > My preference would be to put back the mentioned section in to the > comedia draft, as I see it is relevant to what you describe there. > Said that, do you see any other document where to do it? > > Regards > Marco -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 06:51:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13692 for ; Fri, 14 May 2004 06:51:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaG7-0004Sl-WF for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:49:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EAnhgM017151 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaDj-0003tK-HR for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 06:47:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13469 for ; Fri, 14 May 2004 06:47:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOaDf-00026j-I9 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:47:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOaCf-0001bf-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:46:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOaC1-00016N-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:45:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaAa-00034S-Nn; Fri, 14 May 2004 06:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOa7a-0002ZR-0t for mmusic@optimus.ietf.org; Fri, 14 May 2004 06:40:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13157 for ; Fri, 14 May 2004 06:40:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOa7V-0006tP-Ve for mmusic@ietf.org; Fri, 14 May 2004 06:40:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOa6b-0006Ot-00 for mmusic@ietf.org; Fri, 14 May 2004 06:39:53 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BOa5Z-0005Se-00 for mmusic@ietf.org; Fri, 14 May 2004 06:38:49 -0400 Received: from mangole ([130.209.247.112]:49835) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BOa4z-0005ws-00; Fri, 14 May 2004 11:38:13 +0100 From: Colin Perkins Organization: http://csperkins.org To: Gonzalo Camarillo Subject: Re: [MMUSIC] Comedia draft Date: Fri, 14 May 2004 11:38:15 +0100 User-Agent: KMail/1.6.2 Cc: marco.stura@nokia.com, mmusic@ietf.org, Joerg Ott References: <142DC466081D9B409AAD1DDCA4B21E1D018B0550@esebe016.ntc.nokia.com> <40A49FB3.4070401@ericsson.com> In-Reply-To: <40A49FB3.4070401@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200405141138.15594.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Gonzalo. If a definition for symmetric RTP is important, then it should go into a separate draft. Colin On Friday 14 May 2004 11:30, Gonzalo Camarillo wrote: > Marco, > > I am cc:ing the chairs for advice on this one. > > My opinion is that a draft defining symmetric RTP should discuss the > advantages of it, which types of NATs can be traversed, which ones > cannot be traversed, why an implementer would want to use symmetric RTP > instead or in addition to ICE, etc... and all these discussions do not > belong to the comedia draft at all. > > So, I would propose that symmetric RTP is documented in a separate, > possibly new, document. > > Your suggestion of saving one document by defining symmetric RTP in > comedia does not seem compeling to me, but I would like to hear the > chairs' opinion. I will do what they think it is more appropriate. > > Thanks, > > Gonzalo > > marco.stura@nokia.com wrote: > > Gonzalo, > > > >>I have removed that section from the draft because I believe > >>it is out > >>of the scope of the comedia draft. I want the comedia draft > >>to specify > >>how to describe connection oriented streams in SDP. Explaining how to > >>make RTP streams traverse NATs should be dealt with in a > >>different document. > > > > I see your point. However, the symmetric RTP would make use of the > > setup attribute and all mechanisms defined in comedia draft. Actually > > the section we are talking about was less than half a page. Does it > > really make sense to create a different document just for this? > > > >>That much said, the ICE framework provides a way to traverse > >>NATs which > >>is much better than the one described in comedia-05. > > > > What I propose to document is the symetric RTP not a specific > > discussion how to traverse NAT with RTP streams. > > > >>In any event, if > >>there is still interest to document the latter approach, we > >>can discuss > >>where to do it. > > > > At least I'm interested to document the use of symmetric RTP. > > My preference would be to put back the mentioned section in to the > > comedia draft, as I see it is relevant to what you describe there. > > Said that, do you see any other document where to do it? > > > > Regards > > Marco -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 06:51:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13713 for ; Fri, 14 May 2004 06:51:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaH8-0004gH-Hp for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:50:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EAok5N017988 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaFU-0004I9-Gz for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 06:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13588 for ; Fri, 14 May 2004 06:48:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOaFQ-00037s-FI for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:49:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOaEU-0002bz-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:48:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOaDY-00025w-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaAc-00034w-AM; Fri, 14 May 2004 06:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOa8c-0002ad-TF for mmusic@optimus.ietf.org; Fri, 14 May 2004 06:41:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13214 for ; Fri, 14 May 2004 06:41:54 -0400 (EDT) From: marco.stura@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOa8Y-0007Ok-Qg for mmusic@ietf.org; Fri, 14 May 2004 06:41:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOa7h-0006ur-00 for mmusic@ietf.org; Fri, 14 May 2004 06:41:01 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BOa7E-0006Qo-00 for mmusic@ietf.org; Fri, 14 May 2004 06:40:32 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EAeSB29067; Fri, 14 May 2004 13:40:28 +0300 (EET DST) X-Scanned: Fri, 14 May 2004 13:40:25 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4EAePCi015260; Fri, 14 May 2004 13:40:25 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00WdzAz6; Fri, 14 May 2004 13:40:23 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EAeNH14859; Fri, 14 May 2004 13:40:23 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 May 2004 13:40:12 +0300 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 Subject: RE: [MMUSIC] Comedia draft Date: Fri, 14 May 2004 13:40:12 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0551@esebe016.ntc.nokia.com> Thread-Topic: [MMUSIC] Comedia draft Thread-Index: AcQ5notgyokXim3fQn2bQPerBuURwAAAJG4A To: Cc: , , X-OriginalArrivalTime: 14 May 2004 10:40:12.0248 (UTC) FILETIME=[D5C86580:01C4399F] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Gonzalo, > Your suggestion of saving one document by defining symmetric RTP in=20 > comedia does not seem compeling to me, but I would like to hear the=20 > chairs' opinion. I will do what they think it is more appropriate. That is my amble proposal and question to you. But, as I said, I'm fine with other approaches as well. Marco _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 06:58:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14083 for ; Fri, 14 May 2004 06:58:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaNl-00065e-SE for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:57:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EAvbHi023405 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 06:57:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaNF-0005tc-AL for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 06:57:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13949 for ; Fri, 14 May 2004 06:57:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOaNB-00076n-5D for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:57:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOaM8-0006be-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:55:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOaLD-000680-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:54:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaHN-0004hv-C6; Fri, 14 May 2004 06:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaFI-0004Ha-QN for mmusic@optimus.ietf.org; Fri, 14 May 2004 06:48:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13565 for ; Fri, 14 May 2004 06:48:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOaFE-00036G-M1 for mmusic@ietf.org; Fri, 14 May 2004 06:48:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOaEF-0002a9-00 for mmusic@ietf.org; Fri, 14 May 2004 06:47:48 -0400 Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1BOaD5-0001bz-00 for mmusic@ietf.org; Fri, 14 May 2004 06:46:35 -0400 Received: from imh.informatik.uni-bremen.de (localhost [127.0.0.1]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i4EAkBEJ029759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2004 12:46:12 +0200 (MEST) Received: (from jo@localhost) by imh.informatik.uni-bremen.de (8.12.11/8.12.11/Submit) id i4EAkBGG029758; Fri, 14 May 2004 12:46:11 +0200 (MEST) From: Joerg Ott Message-Id: <200405141046.i4EAkBGG029758@imh.informatik.uni-bremen.de> Subject: Re: [MMUSIC] Comedia draft To: csp@csperkins.org (Colin Perkins) Date: Fri, 14 May 2004 12:46:11 +0200 (MEST) Cc: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo), marco.stura@nokia.com, mmusic@ietf.org, jo@tzi.uni-bremen.de (Joerg Ott) In-Reply-To: <200405141138.15594.csp@csperkins.org> from "Colin Perkins" at May 14, 2004 11:38:15 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Completely agree with Colin. And we should make different functions explicit rather than hiding them. Joerg > I agree with Gonzalo. If a definition for symmetric RTP is important, then > it should go into a separate draft. > > Colin > > > > On Friday 14 May 2004 11:30, Gonzalo Camarillo wrote: > > Marco, > > > > I am cc:ing the chairs for advice on this one. > > > > My opinion is that a draft defining symmetric RTP should discuss the > > advantages of it, which types of NATs can be traversed, which ones > > cannot be traversed, why an implementer would want to use symmetric RTP > > instead or in addition to ICE, etc... and all these discussions do not > > belong to the comedia draft at all. > > > > So, I would propose that symmetric RTP is documented in a separate, > > possibly new, document. > > > > Your suggestion of saving one document by defining symmetric RTP in > > comedia does not seem compeling to me, but I would like to hear the > > chairs' opinion. I will do what they think it is more appropriate. > > > > Thanks, > > > > Gonzalo > > > > marco.stura@nokia.com wrote: > > > Gonzalo, > > > > > >>I have removed that section from the draft because I believe > > >>it is out > > >>of the scope of the comedia draft. I want the comedia draft > > >>to specify > > >>how to describe connection oriented streams in SDP. Explaining how to > > >>make RTP streams traverse NATs should be dealt with in a > > >>different document. > > > > > > I see your point. However, the symmetric RTP would make use of the > > > setup attribute and all mechanisms defined in comedia draft. Actually > > > the section we are talking about was less than half a page. Does it > > > really make sense to create a different document just for this? > > > > > >>That much said, the ICE framework provides a way to traverse > > >>NATs which > > >>is much better than the one described in comedia-05. > > > > > > What I propose to document is the symetric RTP not a specific > > > discussion how to traverse NAT with RTP streams. > > > > > >>In any event, if > > >>there is still interest to document the latter approach, we > > >>can discuss > > >>where to do it. > > > > > > At least I'm interested to document the use of symmetric RTP. > > > My preference would be to put back the mentioned section in to the > > > comedia draft, as I see it is relevant to what you describe there. > > > Said that, do you see any other document where to do it? > > > > > > Regards > > > Marco > > -- > Colin Perkins > http://csperkins.org/ > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 07:03:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14305 for ; Fri, 14 May 2004 07:03:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaQs-0006ef-W1 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 07:00:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EB0odg025576 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 07:00:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaOz-0006IO-B6 for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 06:58:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14068 for ; Fri, 14 May 2004 06:58:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOaOv-0000Ku-5a for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:58:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOaNw-0007bJ-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:57:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOaMx-00073P-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 06:56:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaIL-0004uM-J7; Fri, 14 May 2004 06:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOaGX-0004Ur-30 for mmusic@optimus.ietf.org; Fri, 14 May 2004 06:50:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13649 for ; Fri, 14 May 2004 06:50:04 -0400 (EDT) From: marco.stura@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOaGS-0003dB-Ut for mmusic@ietf.org; Fri, 14 May 2004 06:50:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOaFY-00038u-00 for mmusic@ietf.org; Fri, 14 May 2004 06:49:09 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BOaEv-0002du-00 for mmusic@ietf.org; Fri, 14 May 2004 06:48:29 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EAmPB08874; Fri, 14 May 2004 13:48:25 +0300 (EET DST) X-Scanned: Fri, 14 May 2004 13:48:18 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4EAmIFr026183; Fri, 14 May 2004 13:48:18 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 001IxCRp; Fri, 14 May 2004 13:48:18 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4EAmGH08857; Fri, 14 May 2004 13:48:16 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 14 May 2004 13:48:15 +0300 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-15" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Comedia draft Date: Fri, 14 May 2004 13:48:16 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0552@esebe016.ntc.nokia.com> Thread-Topic: [MMUSIC] Comedia draft Thread-Index: AcQ5n8BYLgLmGO1UQB+FKtSIV1J5XQAAKdnw To: , Cc: , X-OriginalArrivalTime: 14 May 2004 10:48:15.0448 (UTC) FILETIME=[F5CADD80:01C439A0] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Colin, > I agree with Gonzalo. If a definition for symmetric RTP is=20 > important, then=20 > it should go into a separate draft. Fine. Thank you Marco > -----Original Message----- > From: ext Colin Perkins [mailto:csp@csperkins.org] > Sent: 14 May, 2004 13:38 > To: Gonzalo Camarillo > Cc: Stura Marco (Nokia-NET/Helsinki); mmusic@ietf.org; Joerg Ott > Subject: Re: [MMUSIC] Comedia draft >=20 >=20 > I agree with Gonzalo. If a definition for symmetric RTP is=20 > important, then=20 > it should go into a separate draft. >=20 > Colin >=20 >=20 >=20 > On Friday 14 May 2004 11:30, Gonzalo Camarillo wrote: > > Marco, > > > > I am cc:ing the chairs for advice on this one. > > > > My opinion is that a draft defining symmetric RTP should discuss the > > advantages of it, which types of NATs can be traversed, which ones > > cannot be traversed, why an implementer would want to use=20 > symmetric RTP > > instead or in addition to ICE, etc... and all these=20 > discussions do not > > belong to the comedia draft at all. > > > > So, I would propose that symmetric RTP is documented in a separate, > > possibly new, document. > > > > Your suggestion of saving one document by defining symmetric RTP in > > comedia does not seem compeling to me, but I would like to hear the > > chairs' opinion. I will do what they think it is more appropriate. > > > > Thanks, > > > > Gonzalo > > > > marco.stura@nokia.com wrote: > > > Gonzalo, > > > > > >>I have removed that section from the draft because I believe > > >>it is out > > >>of the scope of the comedia draft. I want the comedia draft > > >>to specify > > >>how to describe connection oriented streams in SDP.=20 > Explaining how to > > >>make RTP streams traverse NATs should be dealt with in a > > >>different document. > > > > > > I see your point. However, the symmetric RTP would make use of the > > > setup attribute and all mechanisms defined in comedia=20 > draft. Actually > > > the section we are talking about was less than half a=20 > page. Does it > > > really make sense to create a different document just for this? > > > > > >>That much said, the ICE framework provides a way to traverse > > >>NATs which > > >>is much better than the one described in comedia-05. > > > > > > What I propose to document is the symetric RTP not a specific > > > discussion how to traverse NAT with RTP streams. > > > > > >>In any event, if > > >>there is still interest to document the latter approach, we > > >>can discuss > > >>where to do it. > > > > > > At least I'm interested to document the use of symmetric RTP. > > > My preference would be to put back the mentioned section in to the > > > comedia draft, as I see it is relevant to what you describe there. > > > Said that, do you see any other document where to do it? > > > > > > Regards > > > Marco >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 07:47:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16073 for ; Fri, 14 May 2004 07:47:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOb8i-00004t-T6 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 07:46:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EBk8Tr032762 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 07:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOb3o-0007UB-0S for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 07:41:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15801 for ; Fri, 14 May 2004 07:41:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOb3n-0005xD-6v for mmusic-web-archive@ietf.org; Fri, 14 May 2004 07:41:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOb2n-0005Sf-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 07:40:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOb2E-0004yb-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 07:39:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOazt-0006G6-92; Fri, 14 May 2004 07:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOau2-00058B-Vg for mmusic@optimus.ietf.org; Fri, 14 May 2004 07:30:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15404 for ; Fri, 14 May 2004 07:30:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOau2-0000u9-Cq for mmusic@ietf.org; Fri, 14 May 2004 07:30:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOat3-0000ON-00 for mmusic@ietf.org; Fri, 14 May 2004 07:29:58 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BOas3-0007gL-00 for mmusic@ietf.org; Fri, 14 May 2004 07:28:55 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4EBSrAh006861 for ; Fri, 14 May 2004 13:28:53 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 14 May 2004 13:28:53 +0200 Received: from ericsson.com (sealwp02-135.sw.ericsson.se [153.88.142.135]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KM9PMSPK; Fri, 14 May 2004 13:28:53 +0200 Message-ID: <40A4AD74.80306@ericsson.com> Date: Fri, 14 May 2004 13:28:52 +0200 X-Sybari-Trust: 180a05df 08d63d2e 360d2026 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 CC: "Gonzalo Camarillo (JO/LMF)" , marco.stura@nokia.com, mmusic@ietf.org Subject: Re: [MMUSIC] Comedia draft References: <200405141046.i4EAkBGG029758@imh.informatik.uni-bremen.de> In-Reply-To: <200405141046.i4EAkBGG029758@imh.informatik.uni-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2004 11:28:53.0555 (UTC) FILETIME=[A3047830:01C439A6] Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A Comment, Without having read the changes properly. Are you certain about talking about the same thing when you mention symmetric RTP? I could see that this is two different things: 1. The rather normal property for certain applications that one send and receive RTP data on the same UDP port. 2. The special property to require that one send and receive RTP session to ensure that one can traverse NATs. As the first one is important and need to be supported, while the second and explicit requirements to perform the second can either be implicitly clear by the solution, or need to be explicitly signalled. Depending on what is really the case, the second bullet will either be taken care of automatically, or need extension. In the case of RTP I think one should look at the interface between the AVT draft for RTP framing for connection oriented transport. Cheers Magnus Joerg Ott wrote: > Completely agree with Colin. And we should make different functions > explicit > rather than hiding them. > > Joerg > > >>I agree with Gonzalo. If a definition for symmetric RTP is important, > > then > >>it should go into a separate draft. >> >>Colin >> >> >> >>On Friday 14 May 2004 11:30, Gonzalo Camarillo wrote: >> >>>Marco, >>> >>>I am cc:ing the chairs for advice on this one. >>> >>>My opinion is that a draft defining symmetric RTP should discuss the >>>advantages of it, which types of NATs can be traversed, which ones >>>cannot be traversed, why an implementer would want to use symmetric > > RTP > >>>instead or in addition to ICE, etc... and all these discussions do > > not > >>>belong to the comedia draft at all. >>> >>>So, I would propose that symmetric RTP is documented in a separate, >>>possibly new, document. >>> >>>Your suggestion of saving one document by defining symmetric RTP in >>>comedia does not seem compeling to me, but I would like to hear the >>>chairs' opinion. I will do what they think it is more appropriate. >>> >>>Thanks, >>> >>>Gonzalo >>> >>>marco.stura@nokia.com wrote: >>> >>>>Gonzalo, >>>> >>>> >>>>>I have removed that section from the draft because I believe >>>>>it is out >>>>>of the scope of the comedia draft. I want the comedia draft >>>>>to specify >>>>>how to describe connection oriented streams in SDP. Explaining how > > to > >>>>>make RTP streams traverse NATs should be dealt with in a >>>>>different document. >>>> >>>>I see your point. However, the symmetric RTP would make use of the >>>>setup attribute and all mechanisms defined in comedia draft. > > Actually > >>>>the section we are talking about was less than half a page. Does > > it > >>>>really make sense to create a different document just for this? >>>> >>>> >>>>>That much said, the ICE framework provides a way to traverse >>>>>NATs which >>>>>is much better than the one described in comedia-05. >>>> >>>>What I propose to document is the symetric RTP not a specific >>>>discussion how to traverse NAT with RTP streams. >>>> >>>> >>>>>In any event, if >>>>>there is still interest to document the latter approach, we >>>>>can discuss >>>>>where to do it. >>>> >>>>At least I'm interested to document the use of symmetric RTP. >>>>My preference would be to put back the mentioned section in to the >>>>comedia draft, as I see it is relevant to what you describe there. >>>>Said that, do you see any other document where to do it? >>>> >>>>Regards >>>>Marco >> >>-- >>Colin Perkins >>http://csperkins.org/ >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- 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: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 13:46:24 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08059 for ; Fri, 14 May 2004 13:46:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgji-00046R-H7 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 13:44:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EHigHe015771 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 13:44:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgfQ-000361-Qb for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 13:40:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07650 for ; Fri, 14 May 2004 13:40:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOgfO-0003bu-NO for mmusic-web-archive@ietf.org; Fri, 14 May 2004 13:40:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOged-00035d-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 13:39:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOgcl-00028e-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 13:37:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgVZ-0000mM-PL; Fri, 14 May 2004 13:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgPP-0007oW-4p for mmusic@optimus.ietf.org; Fri, 14 May 2004 13:23:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06695 for ; Fri, 14 May 2004 13:23:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOgPN-0002m0-4e for mmusic@ietf.org; Fri, 14 May 2004 13:23:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOgNM-0001lm-00 for mmusic@ietf.org; Fri, 14 May 2004 13:21:37 -0400 Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1BOgMO-0001E8-00 for mmusic@ietf.org; Fri, 14 May 2004 13:20:36 -0400 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i4EHKZuG009028 for ; Fri, 14 May 2004 10:20:35 -0700 (PDT) Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i4EHKYtj017923 for ; Fri, 14 May 2004 10:20:34 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HXPS6800.CFM for ; Fri, 14 May 2004 10:20:32 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <0100C772-A5CB-11D8-B899-00039372C384@eecs.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mmusic@ietf.org From: "John Lazzaro" Date: Fri, 14 May 2004 10:20:32 -0700 X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Comedia draft Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [from the new comedia- ] > > We define two new values for the proto field: TCP and TCP/TLS. draft-ietf-mmusic-sdp-new-16.txt defines TCP as a proto field, is this going to be deleted from an upcoming -17? Only one standards-track document should claim to define a field, I would think ... Also, previous discussion on the group seemed to suggest that splitting TCP and TLS into separate drafts would have advantages, as TLS requires extra security vetting, see: http://www1.ietf.org/mail-archive/working-groups/mmusic/current/ msg02325.html and its follow-ups ... --- 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 From exim@www1.ietf.org Fri May 14 14:06:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09338 for ; Fri, 14 May 2004 14:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOh2o-0007Uu-Ki for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 14:04:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EI4QoC028815 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 14:04:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOh1v-0007Gw-Jp for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 14:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08938 for ; Fri, 14 May 2004 14:03:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOh1t-0007eU-77 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 14:03:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOgzy-0006gk-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 14:01:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOgye-00061W-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 14:00:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgwb-0006EI-PA; Fri, 14 May 2004 13:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOguR-0005r3-9Q for mmusic@optimus.ietf.org; Fri, 14 May 2004 13:55:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08490 for ; Fri, 14 May 2004 13:55:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOguO-0003Xo-Up for mmusic@ietf.org; Fri, 14 May 2004 13:55:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOgsa-0002XG-00 for mmusic@ietf.org; Fri, 14 May 2004 13:53:52 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BOgrZ-0001w5-00 for mmusic@ietf.org; Fri, 14 May 2004 13:52:50 -0400 Received: from mangole ([130.209.247.112]:58464) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BOgr1-0007rj-00; Fri, 14 May 2004 18:52:15 +0100 From: Colin Perkins Organization: http://csperkins.org To: mmusic@ietf.org Subject: Re: [MMUSIC] Re: Comedia draft Date: Fri, 14 May 2004 18:52:16 +0100 User-Agent: KMail/1.6.2 Cc: "John Lazzaro" References: <0100C772-A5CB-11D8-B899-00039372C384@eecs.berkeley.edu> In-Reply-To: <0100C772-A5CB-11D8-B899-00039372C384@eecs.berkeley.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200405141852.16736.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday 14 May 2004 18:20, John Lazzaro wrote: > > [from the new comedia- ] > > > > We define two new values for the proto field: TCP and TCP/TLS. > > draft-ietf-mmusic-sdp-new-16.txt defines TCP as a proto field, > is this going to be deleted from an upcoming -17? Only one > standards-track document should claim to define a field, I > would think ... I'm intending to remove TCP from the proto field in sdp-new-17, unless there are objections. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 17:06:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27034 for ; Fri, 14 May 2004 17:06:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjfM-0007Wm-9g for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 16:52:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EKqOhW028937 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 16:52:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOjZZ-0003gO-Hc for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 16:46:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24360 for ; Fri, 14 May 2004 16:46:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOjZX-0000TK-Ja for mmusic-web-archive@ietf.org; Fri, 14 May 2004 16:46:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOjVQ-0006nZ-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 16:42:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOjTf-0005fn-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 16:40:19 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BOjQF-0001tG-1Q for mmusic-web-archive@ietf.org; Fri, 14 May 2004 16:36:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOiix-000600-Gk; Fri, 14 May 2004 15:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOiXT-0003VY-2M for mmusic@optimus.ietf.org; Fri, 14 May 2004 15:40:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18033; Fri, 14 May 2004 15:40:08 -0400 (EDT) Message-Id: <200405141940.PAA18033@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 14 May 2004 15:40:08 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-comedia-06.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Connection-Oriented Media Transport in the Session Description Protocol (SDP) Author(s) : D. Yon, G. Camarillo Filename : draft-ietf-mmusic-sdp-comedia-06.txt Pages : 14 Date : 2004-5-14 This document describes how to express media transport over connection-oriented protocols using the Session Description Protocol (SDP). It defines two new protocol identifiers: TCP and TCP/TLS. It also defines the SDP setup attribute, which describes the connection setup procedure, and the SDP reconnect attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-comedia-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-14155118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-comedia-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-14155118.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 14 21:35:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10180 for ; Fri, 14 May 2004 21:35:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOo0Q-0002BV-Bh for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 21:30:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F1UQbE008397 for mmusic-archive@odin.ietf.org; Fri, 14 May 2004 21:30:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOnr5-0000YG-02 for mmusic-web-archive@optimus.ietf.org; Fri, 14 May 2004 21:20:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09522 for ; Fri, 14 May 2004 21:20:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOnr2-0000WS-Co for mmusic-web-archive@ietf.org; Fri, 14 May 2004 21:20:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOnqM-00001Q-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 21:20:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOnpL-0007Ip-00 for mmusic-web-archive@ietf.org; Fri, 14 May 2004 21:18:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOnjk-0007TI-Jd; Fri, 14 May 2004 21:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNqid-0005Ky-3M for mmusic@optimus.ietf.org; Wed, 12 May 2004 06:12:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21327 for ; Wed, 12 May 2004 06:12:03 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNqiZ-0005eh-Dz for mmusic@ietf.org; Wed, 12 May 2004 06:12:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNqhW-00057N-00 for mmusic@ietf.org; Wed, 12 May 2004 06:10:59 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BNqga-0004aj-00 for mmusic@ietf.org; Wed, 12 May 2004 06:10:00 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CA8pH19540; Wed, 12 May 2004 13:08:52 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 13:07:48 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4CA7mjD004886; Wed, 12 May 2004 13:07:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00LvDIYh; Wed, 12 May 2004 13:07:39 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CA7PH14490; Wed, 12 May 2004 13:07:26 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 13:07:24 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 13:07:25 +0300 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: Wed, 12 May 2004 13:07:23 +0300 Message-ID: Thread-Topic: FW: Security requirements review Thread-Index: AcQznSe1OqX1VLwPSqi0h7tS8mf10gEZwtPA To: Cc: , , , , , , , , , , , , , , , , , , X-OriginalArrivalTime: 12 May 2004 10:07:25.0105 (UTC) FILETIME=[EC72B210:01C43808] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: FW: Security requirements review Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Gonzalo Thanks for the comments and questions. Please see in-line... > I would clarify what you had in mind when you wrote the following=20 > requirement: >=20 > REQ DOS-3: It SHOULD be possible to avoid DoS attacks that exhaust > resources of IMG entities by flooding them with IMG metadata. >=20 > What do you mean by "avoid"? Do you mean that the entity=20 > should be able=20 > to run in a stateless mode? Or that it should be able to=20 > identify evil=20 > packets and discard their data? or...? These are both good ideas as options for implementing some kind of = protection against DoS attacks. Here we say "avoid" without specifying how to avoid. Whether the IMG = entity runs in stateless mode or not is an implementation matter so it = is not a requirement to be able to run in stateless mode (other = solutions are allowed). The same is true of discarding evil packets. = These are more security considerations of any solution proposed, and not = so much considerations of the requirements, but it is still relevant = commentary. I suggest that we add the following commentary after REQ = DOS-3... As an example, two potential solutions which may be considered are running an IMG entity in stateless mode or identification and discarding of malicious packets by an IMG entity. > You should clarify both requirements in Section 6.5 (Replay Attacks): >=20 > REQ REP-1: IMG metadata MUST be protected against partial or full > replacement of newer ("current") versions by older ones. >=20 > REQ REP-2: Mechanisms MUST be provided to mitigate replay attacks on > the IMG operations. >=20 > Do you mean that you have to bundle somehow the metadata with the=20 > delivery mechanism? Let's say I receive metadata and I send it to=20 > another user without knowing that a newer version of the metadata is=20 > available... should the other user be able to detect this "reply=20 > attack"? I guess that an explanatory paragraph would help understand=20 > what these requirements really mean. Good point. I think the following text clarifies the meaning for REQ = REP-1: In a system with multiple senders it may not be feasible to prevent some senders delivering older versions of metadata than others - as a result of imperfect sender-sender data consistency. IMG receivers shall tolerate both cases of friendly and malicious sending of older versions without damaging their latest available version. And the following clarification for REQ REP-2: The level of threat from replay attacks varies very much depending on system scale and how well defined or open it is. Thus mitigating relay attacks may lead to different solutions for different systems, independent of the basic delivery method and metadata definitions. A system with multiple senders presents a more challenging scenario for handling replay attacks. As an example, bundling metadata with a security mechanism is one potential solution. How does that sound? Anyone with better clarification text? Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat May 15 01:36:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20752 for ; Sat, 15 May 2004 01:36:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOrpa-0005KK-Ab for mmusic-archive@odin.ietf.org; Sat, 15 May 2004 01:35:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F5ZUpj020476 for mmusic-archive@odin.ietf.org; Sat, 15 May 2004 01:35:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOrgE-0003uC-L5 for mmusic-web-archive@optimus.ietf.org; Sat, 15 May 2004 01:25:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20472 for ; Sat, 15 May 2004 01:25:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOrgB-0001g2-MS for mmusic-web-archive@ietf.org; Sat, 15 May 2004 01:25:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOrfC-0001CN-00 for mmusic-web-archive@ietf.org; Sat, 15 May 2004 01:24:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOreB-0000ir-00 for mmusic-web-archive@ietf.org; Sat, 15 May 2004 01:23:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOrcW-0003ED-Un; Sat, 15 May 2004 01:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOrbJ-0002zZ-Er for mmusic@optimus.ietf.org; Sat, 15 May 2004 01:20:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20340 for ; Sat, 15 May 2004 01:20:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOrbG-00078d-CB for mmusic@ietf.org; Sat, 15 May 2004 01:20:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOraR-0006gT-00 for mmusic@ietf.org; Sat, 15 May 2004 01:19:51 -0400 Received: from av5-2-sn4.m-sp.skanova.net ([81.228.10.111]) by ietf-mx with esmtp (Exim 4.12) id 1BOrZt-0006Bw-00 for mmusic@ietf.org; Sat, 15 May 2004 01:19:17 -0400 Received: by av5-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 6E6DB37E5D; Sat, 15 May 2004 07:18:47 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av5-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 5E4F737E43; Sat, 15 May 2004 07:18:46 +0200 (CEST) Received: from vit (h53n2fls31o265.telia.com [217.208.189.53]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id 9D11B37E45; Sat, 15 May 2004 07:18:46 +0200 (CEST) From: "Gunnar Hellstrom" To: "mmusic IETF" Cc: "Toip list" , "Colin Perkins" Date: Sat, 15 May 2004 07:18:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Support for m=text in draft-ietf-mmusic-sdp-new-16 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Colin and all, I reviewed draft-ietf-mmusic-sdp-new-16 and found it good. I am especiall= y satisfied to see that the text medium is now explicitly declared to be among the ones you can specify in the m-line. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-16.txt Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m Omnitor AB Renathv=E4gen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue May 18 05:33:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28003 for ; Tue, 18 May 2004 05:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0u9-0000Bx-Fd for mmusic-archive@odin.ietf.org; Tue, 18 May 2004 05:28:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I9Sv19000721 for mmusic-archive@odin.ietf.org; Tue, 18 May 2004 05:28:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0lM-000755-0b for mmusic-web-archive@optimus.ietf.org; Tue, 18 May 2004 05:19:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27257 for ; Tue, 18 May 2004 05:19:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0lI-0002sj-Nz for mmusic-web-archive@ietf.org; Tue, 18 May 2004 05:19:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0kA-00024b-00 for mmusic-web-archive@ietf.org; Tue, 18 May 2004 05:18:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ0is-0001Yi-00 for mmusic-web-archive@ietf.org; Tue, 18 May 2004 05:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0a0-0003zw-Au; Tue, 18 May 2004 05:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0XH-00035I-Up for mmusic@optimus.ietf.org; Tue, 18 May 2004 05:05:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25962 for ; Tue, 18 May 2004 05:05:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0XE-0003r0-OY for mmusic@ietf.org; Tue, 18 May 2004 05:05:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0V3-000391-00 for mmusic@ietf.org; Tue, 18 May 2004 05:03:03 -0400 Received: from mailgate2.ebu.ch ([194.158.3.232]) by ietf-mx with esmtp (Exim 4.12) id 1BQ0UB-0002PE-00 for mmusic@ietf.org; Tue, 18 May 2004 05:02:07 -0400 Received: from gnvasrelay1b.gva.ebu.ch (unverified [10.73.222.59]) by mailgate2.ebu.ch (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Tue, 18 May 2004 10:59:54 +0200 Received: from gnvasmail1a.gva.ebu.ch ([10.73.222.209]) by gnvasrelay1b.gva.ebu.ch with Microsoft SMTPSVC (5.0.2195.6713); Tue, 18 May 2004 11:01:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43CB6.B9BBA5AD" Date: Tue, 18 May 2004 11:01:37 +0200 Message-ID: <9BB211A65FCBFD43B95F67BA2485759DFB8B0D@gnvasmail1a.gva.ebu.ch> Thread-Topic: Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt Thread-Index: AcQ44OgvCQAhYFBbQpS5bkdDVW94TAD1av3Q From: "Evain, Jean-Pierre" To: X-OriginalArrivalTime: 18 May 2004 09:01:37.0058 (UTC) FILETIME=[B9B50820:01C43CB6] Subject: [MMUSIC] FW: Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43CB6.B9BBA5AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, second attempt after having sent it to the admin first. Thanks in advance for your comments. Best regards, Jean-Pierre > -----Original Message----- > From: Evain, Jean-Pierre =20 > Sent: jeudi, 13. mai 2004 13:53 > To: 'mmusic-admin@ietf.org' > Subject: Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt >=20 > Dear all, >=20 > TV-Anytime has a look at the > draft-luoma-mmusic-img-metadata-envelope-00.txt. >=20 > We don't know exactly what is the status of this draft but we would like > to submit the following comments: >=20 > 1. We believe fragment identification and versioning are at the wrong > level within the protocol stack. It would require a receiver to acquire > the entire envelope structure (which also contains the metadata fragment) > before the data can be parsed and its version and fragment identifier > extracted. Instead, this information should be signalled within the packet > header carrying the envelope. This is to enable a receiver to efficiently > filter/monitor the stream for metadata updates. > 2. For efficiency reasons it would be advantageous for an IP packet to be > able to carry more than one envelope. > 3. It is not clear whether the receiver should have a validating parser. > 4. It should not be a requirement to decrypt the envelope to acquire the > version and fragment ID. > 5. The Envelope schema says that there can be multiple XML payloads but > they would all have the same version and fragment ID. We don't thing this > is right. > 6. The solution implies that the data MUST be delivered as raw XML. What > about binarisation?=20 > 7. No Syntax has been provided for IMG QUERY, IMG ANNOUNCE, IMG RESOLVE, > IMG NOTIFY, and IMG SUBSCRIBE. > 8. How do you identify where a Delta goes within the identified fragment. > i.e. what is its XPath? > 9. TV-Anytime already provides an envelope. More information can be found > in the technical specification ETSI 102 822 -3/2 (www.etsi.org). In > addition it further explains the requirements on the delivery layer. > 10. It is not clear what the purpose of the expiry date within the > envelope is. I think this is application specific. If it stays it should > be made clear what the semantics are. What is the use case? >=20 > What do you think ? >=20 > Best regards, >=20 > Jean-Pierre Evain >=20 >=20 > =20 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** =20 ------_=_NextPart_001_01C43CB6.B9BBA5AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt</TIT= LE> </HEAD> <BODY> <!-- Converted from text/rtf format --> <P><SPAN LANG=3D"fr-ch"><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dea= r all,</FONT></SPAN> </P> <P><SPAN LANG=3D"fr-ch"><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">sec= ond attempt after having sent it to the admin first.</FONT></SPAN> </P> <P><SPAN LANG=3D"fr-ch"><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Tha= nks in advance for your comments.</FONT></SPAN> </P> <P><SPAN LANG=3D"fr-ch"><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Bes= t regards,</FONT></SPAN> </P> <P><SPAN LANG=3D"fr-ch"><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Jea= n-Pierre</FONT></SPAN> </P> <P><SPAN LANG=3D"fr-ch"><FONT FACE=3D"Arial"></FONT> <FONT SIZE=3D1 FA= CE=3D"Tahoma">-----Original Message-----</FONT></SPAN> <BR><SPAN LANG=3D"fr-ch"><B><FONT SIZE=3D1 FACE=3D"Tahoma">From:  </FO= NT></B> <FONT SIZE=3D1 FACE=3D"Tahoma">Evain, Jean-Pierre  </FONT></SP= AN> <BR><SPAN LANG=3D"fr-ch"><B><FONT SIZE=3D1 FACE=3D"Tahoma">Sent:  = ;</FONT></B> <FONT SIZE=3D1 FACE=3D"Tahoma">jeudi, 13. mai 2004 13:53</FONT= ></SPAN> <BR><SPAN LANG=3D"fr-ch"><B><FONT SIZE=3D1 FACE=3D"Tahoma">To:  &= nbsp; </FONT></B> <FONT SIZE=3D1 FACE=3D"Tahoma">'mmusic-admin@ietf.or= g'</FONT></SPAN> <BR><SPAN LANG=3D"fr-ch"><B><FONT SIZE=3D1 FACE=3D"Tahoma">Subject: &n= bsp;     </FONT></B> <FONT SIZE=3D1 FACE=3D"Tahoma= ">Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt</FONT></SPAN> </P> <P><SPAN LANG=3D"fr-ch"><FONT SIZE=3D2 FACE=3D"Arial">Dear all,</FONT></SPA= N> </P> <P><SPAN LANG=3D"fr-ch"><FONT SIZE=3D2 FACE=3D"Arial">TV-Anytime has a look= at the</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FON= T SIZE=3D2 FACE=3D"Courier New">draft-luoma-mmusic-img-metadata-envelope-00= .txt.</FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">We don't know e= xactly what is the status of this draft but we would like to submit the fol= lowing comments:</FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">1. We believe f= ragment identification and versioning are at the wrong level within the pro= tocol stack. It would require a receiver to acquire the entire envelope str= ucture (which also contains the metadata fragment) before the data can be p= arsed and its version and fragment identifier extracted. Instead, this info= rmation should be signalled within the packet header carrying the envelope.= This is to enable a receiver to efficiently filter/monitor the stream for = metadata updates.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">2. For efficien= cy reasons it would be advantageous for an IP packet to be able to carry mo= re than one envelope.</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">3. It is not c= lear whether the receiver should have a validating parser.</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">4. It should n= ot be a requirement to decrypt the envelope to acquire the version and frag= ment ID.</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">5. The Envelop= e schema says that there can be multiple XML payloads but they would all ha= ve the same version and fragment ID. We don't thing this is right.</FONT></= SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">6. The solution= implies that the data MUST be delivered as raw XML. What about binarisatio= n? </FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">7. No Syntax h= as been provided for IMG QUERY, IMG ANNOUNCE, IMG RESOLVE, IMG NOTIFY, and = IMG SUBSCRIBE.</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">8. How do you = identify where a Delta goes within the identified fragment. i.e. what is it= s XPath?</FONT></SPAN> <BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">9. TV-Anytime = already provides an envelope. More information can be found in the technica= l specification ETSI 102 822 -3/2 (</FONT></SPAN><A HREF=3D"file://www.etsi= .org"><SPAN LANG=3D"en-us"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Cour= ier New">www.etsi.org</FONT></U></SPAN></A><SPAN LANG=3D"en-us"><FONT SIZE= =3D2 FACE=3D"Courier New">). In addition it further explains the requiremen= ts on the delivery layer.</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">10. It is not c= lear what the purpose of the expiry date within the envelope is. I think th= is is application specific. If it stays it should be made clear what the se= mantics are. What is the use case?</FONT></SPAN></P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">What do you thi= nk ?</FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">Best regards,</= FONT></SPAN> </P> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New">Jean-Pierre Eva= in</FONT></SPAN> </P> <BR> <P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT> </= SPAN> </P> <FONT SIZE=3D3><BR> <BR> **********************************************************************<BR> This email and any files transmitted with it are confidential and<BR> intended solely for the use of the individual or entity to whom they<BR> are addressed. If you have received this email in error please notify<BR> the system manager.<BR> <BR> **********************************************************************<BR> <BR> </FONT> </BODY> </HTML> ------_=_NextPart_001_01C43CB6.B9BBA5AD-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue May 18 10:23:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17637 for <mmusic-archive@odin.ietf.org>; Tue, 18 May 2004 10:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5CW-0005tQ-BR for mmusic-archive@odin.ietf.org; Tue, 18 May 2004 10:04:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IE4CrS022620 for mmusic-archive@odin.ietf.org; Tue, 18 May 2004 10:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ588-0003L8-6V for mmusic-web-archive@optimus.ietf.org; Tue, 18 May 2004 09:59:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15346 for <mmusic-web-archive@ietf.org>; Tue, 18 May 2004 09:59:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ586-0007hO-6L for mmusic-web-archive@ietf.org; Tue, 18 May 2004 09:59:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ56l-0007IE-00 for mmusic-web-archive@ietf.org; Tue, 18 May 2004 09:58:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ55x-0006ue-00 for mmusic-web-archive@ietf.org; Tue, 18 May 2004 09:57:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4y1-000051-9K; Tue, 18 May 2004 09:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4r7-0006Am-Jb for mmusic@optimus.ietf.org; Tue, 18 May 2004 09:42:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14743 for <mmusic@ietf.org>; Tue, 18 May 2004 09:42:02 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4r4-0001Fb-Ua for mmusic@ietf.org; Tue, 18 May 2004 09:42:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ4qC-0000sm-00 for mmusic@ietf.org; Tue, 18 May 2004 09:41:11 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BQ4pK-0000U4-00 for mmusic@ietf.org; Tue, 18 May 2004 09:40:14 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4IDeAB11917; Tue, 18 May 2004 16:40:10 +0300 (EET DST) X-Scanned: Tue, 18 May 2004 16:40:00 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4IDe07Q001851; Tue, 18 May 2004 16:40:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00LHrkQ6; Tue, 18 May 2004 16:39:58 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4IDdpH24338; Tue, 18 May 2004 16:39:51 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 18 May 2004 16:39:50 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 18 May 2004 16:39:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43CDD.9701E344" Subject: RE: [MMUSIC] FW: Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt Date: Tue, 18 May 2004 16:39:49 +0300 Message-ID: <D0299AFF29E01E478321564030AD6909539664@trebe003.europe.nokia.com> Thread-Topic: Comments on draft-luoma-mmusic-img-metadata-envelope-00.txt Thread-Index: AcQ44OgvCQAhYFBbQpS5bkdDVW94TAD1av3QAAK1SRA= To: <evain@ebu.ch> Cc: <mmusic@ietf.org> X-OriginalArrivalTime: 18 May 2004 13:39:49.0626 (UTC) FILETIME=[9740C5A0:01C43CDD] Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe> List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org> 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> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C43CDD.9701E344 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jean-Pierre =20 Thanks for the comments (I'm replying on Pekka's behalf since he's not = in the office until June). =20 See in-line... W e don't know exactly what is the status of this draft but we = would like to submit the following comments: =20 =20 It's an individual draft aimed at given an example of what the metadata = envelope could look like, and hopefully accelerating this the work on a = WG solution if MMUSIC charters this. It's also long overdue an update. =20 1. We believe fragment identification and versioning are at the wrong = level within the protocol stack. It would require a receiver to acquire = the entire envelope structure (which also contains the metadata = fragment) before the data can be parsed and its version and fragment = identifier extracted. Instead, this information should be signalled = within the packet header carrying the envelope. This is to enable a = receiver to efficiently filter/monitor the stream for metadata updates. =20 In the sense that if you have the fragment embedded then the XML does = not formally get the complete envelope until after all the fragment data = so potentially the whole fragment would be passed to the application, = but that's not the only design. I'm pretty sure that it would be = possible to extract the version and fragment id from the envelope before = the final /metadataEnvelope> is received if the XML parser is designed = to handle this - please educate me if I'm wrong! =20 Note that the I-D has not been updated for some time (it's overdue for = an update). As a result, it emphasises only the "embedded fragment" = method and=20 not also the "referenced fragment" method. The latter enables the = envelope data to be received somewhat independently of the fragment = (e.g. separate objects within a FLUTE session) and seems to meet your = use case. This will be corrected when the I-D is updated. =20 To put the envelope data into the transport protocol header (with = fragment payload) was considered in the first stage of envelope = discussion, but since it is protocol bound, it is not transport = independent and so does not meet the IMG requirements. (Secondary issues = concerned transport efficiency). =20 2. For efficiency reasons it would be advantageous for an IP packet = to be able to carry more than one envelope.=20 =20 Where fragments are generally smaller than half the MTU, two fragments = in an IP packet has better header efficiency - I see the point. =20 But this is more a transport into IP packing and fragmentation issue. In = any case, the purpose a single metadata envelope is to enable the = transport independent use of a single metadata fragment. Grouping of = fragments into larger fragments/blocks with a single combined envelope = is fine, but a data model issue, not envelope. =20 I'll take another look into this idea so feel free to ask again anytime = (my opinion should not change, but that's not mandatory :) =20 3. It is not clear whether the receiver should have a validating = parser.=20 =20 Can you be a little more specific please? (Whether the envelope parser = should be validating?) In any case, any XML which is not valid according = to the schema should be rejected. =20 4. It should not be a requirement to decrypt the envelope to acquire = the version and fragment ID.=20 =20 Yes. It should be recommended that this info is not encrypted (the IMG = requirements cover the relay and proxy cases which require this for = versioning without seeing the content) - a little more simple than the = SAP/SDP approach. In some cases the provider of a closed system may wish = encrypt the envelope, but in most cases I expect not. =20 The envelope I-D does need to make this clear. =20 5. The Envelope schema says that there can be multiple XML payloads = but they would all have the same version and fragment ID. We don't thing = this is right.=20 =20 Only one "payload" per envelope (payload =3D metadata fragment, whether = it is referenced or embedded). =20 In the sense that the same version of a pointer, delta and complete = instantiations of the same metadata fragment will all be identified by = the same URI, it is possible for the "payload" to differ (delta vs. = complete) for the same URI+version. =20 6. The solution implies that the data MUST be delivered as raw XML. = What about binarisation?=20 =20 "Binarisation" (for compression, encryption, etc) needs supporting. For = a "referenced fragment" it's obvious (e.g. FLUTE FDT MIME type or = content-encoding gives it away). For an embedded fragment the "type" of = the embedded object needs specifying in the "payload tag". (Such as = ASCII or XML). If you consider embedded fragments as binary objects = necessary please say and we'll look into the schema change needed (and = any suggested new schema are welcome too). =20 7. No Syntax has been provided for IMG QUERY, IMG ANNOUNCE, IMG = RESOLVE, IMG NOTIFY, and IMG SUBSCRIBE.=20 =20 The envelope is not responsible for that functionality or the = identification of that functionality. The instantiation of these = operations would specify any use of the envelope (e.g. an IMG ANNOUNCE = instantiation could specify the use of envelope and FLUTE). =20 8. How do you identify where a Delta goes within the identified = fragment. i.e. what is its XPath? =20 Could be done my means of the MIME type of the URI'd fragment - e.g. as = a type of delta (with IANA registration if for general Internet use). It = is assumed that the "delta type" deals with "placing itself" in the = fragment. E.g. binary diff and patch, and use of Xpath are good = examples. =20 9. TV-Anytime already provides an envelope. More information can be = found in the technical specification ETSI 102 822 -3/2 ( = <file://www.etsi.org/> www.etsi.org). In addition it further explains = the requirements on the delivery layer. =20 Excellent. I think the TVA review of IMG Requirements and IMG Framework = was very positive and showed that TVA would fit smoothly into the IMG = framework. It's not surprising that the need for a metadata envelope is = common. =20 I just had a whirlwind read of "ETSI TS 102 822-3-2 V1.1.1 (2003-10)" = and formed these views (since I'm a relative TVA novice, please set me = straight on any misunderstandings): * TVA "Encapsulation Format" fulfils a very similar function to IMG = "metadata envelope" * TVA "container" (or "access unit") is not the same as metadata = envelope, although it seems similar in the case of "one contained = fragment". However the purpose if different. (The "container" is to = group the delivery of several fragments together like with DSM-CC object = carousel "containers" over MPEG-2 TS). * When TVA "container" and "encapsulation" are taken together, they fit = roughly into the same place in the protocol stack as IMG "envelope" * TVA "container" and "encapsulation" are binary coded and provide only = BiM payloads (although TVA registered numbers could be added for other = TVA fragment syntaxes). * IMG "envelope" is XML coded and its purpose is to allows any payload = syntax. (BiM being a possible payload syntax or an XML fragment = content-encoding - I think the latter is more generic). * IMG envelope could be content-encoded (e.g. gzip, BiM, etc) and it may = be feasible to consider specifying "the TVA encapsulation binary = encoding of an XML IMG envelope" - but that's beyond the scope of the = I-D we're talking about * The IMG envelope uses a URI to identify fragments, TVA uses a 24 bit = number. This makes enabling "global scope" straightforward for IMGs = (although a 24 bit number, bit-encoded or URN, is perfectly suited to = "organization/operator scope"). * Both IMG "envelope" and TVA "encapsulation" provide a version number = for the fragment (as well as the id). * IMG "envelope" also provides expiry data. TVA defines messages (e.g. = delete) separate from the envelope to achieve some of this = functionality. * IMG "envelope" could be transported separately from the fragments = (e.g. different objects in a FLUTE session). It would be relatively = trivial to enable TVA "encapsulation" to do the same - possibly with a = name change :) =20 So (IMHO) IMG envelope and TVA encapsulation have almost the same = purpose in relation to their payload (although different payload = scopes). IMG "envelope" has wider applicability, although it could be = content-encoded into a bit-encoding equal to the TVA "encapsulation" so = that TVA ETSI standards could be used "as is" (although I would prefer = the ability to carry TVA over any IMG transport). =20 10. It is not clear what the purpose of the expiry date within the = envelope is. I think this is application specific. If it stays it should = be made clear what the semantics are. What is the use case? =20 It expires that metadata fragment, so that: (a) I client would know that = it needs to check it's metadata is consistent with the server, (b) if = the metadata is no longer of use it is fine to discard, (c) the same = fragment version may be unchanged but have it's time validity changed = (so the client would know that an update of the fragment is unnecessary = although the expiry is extended or shortened) =20 What do you think ?=20 =20 Excellent comments, most of which need to be reflected in the I-D. If = you have suggested I-D text and a place to put them please send by email = - this is always welcome. Otherwise, stay posted and I guess there will = be an update before the end of June. =20 Cheers, Rod. =20 =20 ------_=_NextPart_001_01C43CDD.9701E344 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <TITLE>FW: Comments on = draft-luoma-mmusic-img-metadata-envelope-00.txt
Hi=20 Jean-Pierre
 
Thanks=20 for the comments (I'm replying on Pekka's behalf since he's not in the = office=20 until June).
 
See=20 in-line...
   =20  W  e don't know exactly what is = the status=20 of this draft but we would like to submit the following=20 comments:  
 
It's an individual draft aimed at given an = example of=20 what the metadata envelope could look like, and hopefully accelerating = this the=20 work on a WG solution if MMUSIC charters this. It's also long overdue an = update.
 
   1. We believe fragment = identification and=20 versioning are at the wrong level within the protocol stack. It would = require a=20 receiver to acquire the entire envelope structure (which also contains = the=20 metadata fragment) before the data can be parsed and its version and = fragment=20 identifier extracted. Instead, this information should be signalled = within the=20 packet header carrying the envelope. This is to enable a receiver to = efficiently=20 filter/monitor the stream for metadata=20 updates.
 
In the sense that if you have the fragment embedded then the = XML does not=20 formally get the complete envelope until after all the fragment data so=20 potentially the whole fragment would be passed to the application, but = that's=20 not the only design. I'm pretty sure that it would be possible to = extract the=20 version and fragment id from the envelope before the final = /metadataEnvelope>=20 is received if the XML parser is designed to handle this - please = educate me if=20 I'm wrong!
 
Note that the = I-D has not=20 been updated for some time (it's overdue for an update). As a result, it = emphasises only the "embedded fragment" method and=20
not also the = "referenced=20 fragment" method. The latter enables the envelope data to be received = somewhat=20 independently of the fragment (e.g. separate objects within a FLUTE = session) and=20 seems to meet your use case. This will be corrected when the I-D is=20 updated.
 
To put = the envelope=20 data into the transport protocol header (with fragment payload) was = considered=20 in the first stage of envelope discussion, but since it is protocol = bound, it is=20 not transport independent and so does not meet the IMG requirements. = (Secondary=20 issues concerned transport=20 efficiency).
 
   2. For efficiency = reasons it=20 would be advantageous for an IP packet to be able to carry more than one = envelope.
 
Where = fragments are generally=20 smaller than half the MTU, two fragments in an IP packet has better = header=20 efficiency - I see the point.
 
But this is = more a transport=20 into IP packing and fragmentation issue. In any case, the purpose = a single=20 metadata envelope is to enable the transport independent use of a single = metadata fragment. Grouping of fragments into larger fragments/blocks = with a=20 single combined envelope is fine, but a data model issue, not=20 envelope.
 
I'll take another look = into this=20 idea so feel free to ask again anytime (my opinion should not change, = but that's=20 not mandatory :)
 
   3. It is not clear whether the = receiver should=20 have a validating parser. =
 
Can you be a little more specific please? (Whether the envelope = parser=20 should be validating?) In any case, any XML which is not valid according = to the=20 schema should be rejected.
 
  =20 4. It should not be a requirement to decrypt the = envelope to=20 acquire the version and fragment ID.=20
 
Yes. It should be recommended that this info is not encrypted = (the IMG=20 requirements cover the relay and proxy cases which require this for = versioning without seeing the content) - a little more simple than the = SAP/SDP=20 approach. In some cases the provider of a closed system may wish encrypt = the=20 envelope, but in most cases I expect=20 not.
 
The = envelope I-D does=20 need to make this clear.
 
   5. The Envelope schema says that there = can be=20 multiple XML payloads but they would all have the same version and = fragment ID.=20 We don't thing this is right. 
 
Only one "payload" per = envelope (payload =3D=20 metadata fragment, whether it is referenced or=20 embedded).
 
In the sense that the = same version=20 of a pointer, delta and complete instantiations of the same metadata = fragment=20 will all be identified by the same URI, it is possible for the "payload" = to=20 differ (delta vs. complete) for the same=20 URI+version.
 
   6.=20 The solution implies that the data MUST be delivered as raw XML. What = about=20 binarisation?
 
"Binarisation" (for compression, encryption, etc) needs=20 supporting. For a "referenced fragment" it's obvious (e.g. FLUTE FDT = MIME type=20 or content-encoding gives it away). For an embedded fragment the "type" = of the=20 embedded object needs specifying in the "payload tag". (Such as ASCII or = XML).=20 If you consider embedded fragments as binary objects necessary please = say and=20 we'll look into the schema change needed (and any suggested = new schema are=20 welcome too).
 
   7. No Syntax has been provided for IMG QUERY, = IMG=20 ANNOUNCE, IMG RESOLVE, IMG NOTIFY, and IMG SUBSCRIBE.=20
 
The=20 envelope is not responsible for that functionality or the identification = of that=20 functionality. The instantiation of these operations would specify any = use of=20 the envelope (e.g. an IMG ANNOUNCE instantiation could specify the use = of=20 envelope and FLUTE).
 
   8. How do you identify where a Delta goes = within the=20 identified fragment. i.e. what is its=20 XPath?
 
Could be done my means of the MIME type of the URI'd = fragment -=20 e.g. as a type of delta (with IANA registration if for general Internet = use). It=20 is assumed that the "delta type" deals with "placing itself" = in the=20 fragment. E.g. binary diff and patch, and use of Xpath are good=20 examples.
 
   9.=20 TV-Anytime already provides an envelope. More information can be found = in the=20 technical specification ETSI 102 822 -3/2 (www.etsi.org). In addition it further = explains the=20 requirements on the delivery layer.
 
Excellent. I think the TVA review of IMG = Requirements=20 and IMG Framework was very positive and showed that TVA would fit = smoothly into=20 the IMG framework. It's not surprising that the need for a metadata = envelope is=20 common.
 
I just had a whirlwind read of "ETSI TS = 102 822-3-2=20 V1.1.1 (2003-10)" and formed these views (since I'm a relative TVA = novice,=20 please set me straight on any = misunderstandings):
* TVA "Encapsulation Format" fulfils a very = similar=20 function to IMG "metadata envelope"
* TVA "container" (or "access unit") is not = the same as=20 metadata envelope, although it seems similar in the case of "one = contained=20 fragment". However the purpose if different. (The "container" is to = group the=20 delivery of several fragments together like with DSM-CC object carousel=20 "containers" over MPEG-2 TS).
* When TVA "container" and "encapsulation" = are taken=20 together, they fit roughly into the same place in the protocol stack as = IMG=20 "envelope"
* TVA "container" and "encapsulation" are = binary coded=20 and provide only BiM payloads (although TVA registered numbers could be = added=20 for other TVA fragment syntaxes).
* IMG "envelope" is XML coded and its = purpose is to=20 allows any payload syntax. (BiM being a possible payload syntax or an = XML=20 fragment content-encoding - I think the latter is more=20 generic).
* IMG envelope could be content-encoded = (e.g. gzip, BiM,=20 etc) and it may be feasible to consider specifying "the TVA = encapsulation binary=20 encoding of an XML IMG envelope" - but that's beyond the scope of the = I-D we're=20 talking about
* The IMG envelope uses a URI to identify = fragments, TVA=20 uses a 24 bit number. This makes enabling "global scope" straightforward = for=20 IMGs (although a 24 bit number, bit-encoded or URN, is perfectly suited = to=20 "organization/operator scope").
* Both IMG "envelope" and TVA = "encapsulation" provide a=20 version number for the fragment (as well as the = id).
* IMG "envelope" also provides expiry data. = TVA defines=20 messages (e.g. delete) separate from the envelope to achieve some of = this=20 functionality.
* IMG "envelope" could be transported = separately from=20 the fragments (e.g. different objects in a FLUTE session). It would be=20 relatively trivial to enable TVA "encapsulation" to do the same - = possibly with=20 a name change :)
 
So (IMHO) IMG envelope and TVA encapsulation = have almost=20 the same purpose in relation to their payload (although different = payload=20 scopes). IMG "envelope" has wider applicability, although it could be=20 content-encoded into a bit-encoding equal to the TVA "encapsulation" so = that TVA=20 ETSI standards could be used "as is" (although I would prefer the = ability to=20 carry TVA over any IMG transport).
 
   10. It is not = clear what=20 the purpose of the expiry date within the envelope is. I think this is=20 application specific. If it stays it should be made clear what the = semantics=20 are. What is the use case?
 
It expires that metadata fragment, so = that: (a) I=20 client would know that it needs to check it's metadata is consistent = with the=20 server, (b) if the metadata is no longer of use it is fine to discard, = (c) the=20 same fragment version may be unchanged but have it's time validity = changed (so=20 the client would know that an update of the fragment is unnecessary = although the=20 expiry is extended or shortened)
 
What do you think ? =
 
Excellent comments, most of which need to be reflected in the = I-D. If you=20 have suggested I-D text and a place to put them please send by email = - this=20 is always welcome. Otherwise, stay posted and I guess there will be an = update=20 before the end of June.
 
Cheers, Rod.
 
 
------_=_NextPart_001_01C43CDD.9701E344-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue May 18 11:28:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22768 for ; Tue, 18 May 2004 11:28:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6J1-0007Kz-0W for mmusic-archive@odin.ietf.org; Tue, 18 May 2004 11:14:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IFEwuK028205 for mmusic-archive@odin.ietf.org; Tue, 18 May 2004 11:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ6G6-0006lR-L4 for mmusic-web-archive@optimus.ietf.org; Tue, 18 May 2004 11:11:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21975 for ; Tue, 18 May 2004 11:11:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ6G4-00012f-0h for mmusic-web-archive@ietf.org; Tue, 18 May 2004 11:11:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ6F8-0000wx-00 for mmusic-web-archive@ietf.org; Tue, 18 May 2004 11:10:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ6E9-0000tS-00 for mmusic-web-archive@ietf.org; Tue, 18 May 2004 11:09:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ67Q-0003bL-Db; Tue, 18 May 2004 11:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5V0-0007TL-7x for mmusic@optimus.ietf.org; Tue, 18 May 2004 10:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17632 for ; Tue, 18 May 2004 10:23:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5Ux-0001E6-SI for mmusic@ietf.org; Tue, 18 May 2004 10:23:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5U1-0000qA-00 for mmusic@ietf.org; Tue, 18 May 2004 10:22:17 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5TR-0000SP-00; Tue, 18 May 2004 10:21:41 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4IELeAh022890; Tue, 18 May 2004 16:21:40 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 16:21:40 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.60]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LFSY489V; Tue, 18 May 2004 16:22:16 +0200 Message-ID: <40AA1BF4.2000908@ericsson.com> Date: Tue, 18 May 2004 16:21:40 +0200 X-Sybari-Trust: 5a5e7d8b 08d63d2e 06b283dd 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2004 14:21:40.0449 (UTC) FILETIME=[6FD1F510:01C43CE3] Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Soliciting comments on Offer/Answer procedures Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Any reply to this mail should be directed to the AVT mailing list. The mail is BCC to MMUSIC, SIP and SIPPING to avoid cross postings. In the RTP payload format for the H.264/AVC video codec, we authors had to write a rather special procedure in the offer/answer. This procedure is there to make the distribution of the video codecs parameter sets work. However we would like to have further review from people knowing SIP and Offer/Answer thoroughly, to ensure that we have not created any problems. Therefore I would be very thankful if you could take a look at: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-06.txt and review the Offer/Answer consideration section (8.2). I wouldn't expect that you will need to read more than some further parts of section 8, and possibly some of the introduction in section 1 for background information. Any comments is desired within two weeks, i.e. before 9th of June. Thanks 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: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 20 12:19:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29037 for ; Thu, 20 May 2004 12:19:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpyc-00062W-Bz for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 12:00:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KG0wY5023215 for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 12:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpiM-0000er-Ip for mmusic-web-archive@optimus.ietf.org; Thu, 20 May 2004 11:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25444 for ; Thu, 20 May 2004 11:44:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpiL-0006Ds-Ev for mmusic-web-archive@ietf.org; Thu, 20 May 2004 11:44:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpgL-0005y0-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 11:42:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQpeg-0005fo-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 11:40:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQp7Y-0004bz-AI; Thu, 20 May 2004 11:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQoOn-0003tE-W7 for mmusic@optimus.ietf.org; Thu, 20 May 2004 10:19:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19285 for ; Thu, 20 May 2004 10:19:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQoOl-0004Cx-I5 for mmusic@ietf.org; Thu, 20 May 2004 10:19:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQoNo-0003ze-00 for mmusic@ietf.org; Thu, 20 May 2004 10:18:53 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1BQoN6-0003ev-00 for mmusic@ietf.org; Thu, 20 May 2004 10:18:09 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4KEHZV2009750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 May 2004 07:17:36 -0700 (PDT) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4KEHX3O003642 for ; Thu, 20 May 2004 07:17:33 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 07:17:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 May 2004 07:17:47 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F010E27A1@NAEX01.na.qualcomm.com> Thread-Topic: Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) Thread-Index: AcQ+dTHjU7rmwCYiTl+mom1wW92isg== From: "Barany, Pete" To: X-OriginalArrivalTime: 20 May 2004 14:17:33.0692 (UTC) FILETIME=[319153C0:01C43E75] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, In Section 8.4 of RFC 3264 "An Offer/Answer Model with the Session Description Protocol (SDP)", the following statement is made: -->BEGIN RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer. -->END Question: The statement "An agent MUST be capable of receiving SDP with a Connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer." Does this apply also to IPv6 (0:0:0:0:0:0:0:0, or in abbreviated format ::)? There is some mention about putting a call on hold early in the paragraph above and how this doesn't work for IPv6 ... therefore, this is the cause of my confusion. Thnx. - Pete _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 20 12:57:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02001 for ; Thu, 20 May 2004 12:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqnd-00070H-S3 for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 12:53:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGrfpn026922 for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 12:53:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqYW-00032I-5S for mmusic-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:38:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00227 for ; Thu, 20 May 2004 12:38:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqYU-0004BK-L7 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:38:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqXU-000446-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:37:01 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqWW-0003yL-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:36:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqBP-0003Kv-EK; Thu, 20 May 2004 12:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQpsa-0003eS-HR for mmusic@optimus.ietf.org; Thu, 20 May 2004 11:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26893 for ; Thu, 20 May 2004 11:54:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQpsZ-00001N-9b for mmusic@ietf.org; Thu, 20 May 2004 11:54:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQprf-0007lq-00 for mmusic@ietf.org; Thu, 20 May 2004 11:53:48 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BQpqk-0007au-00 for mmusic@ietf.org; Thu, 20 May 2004 11:52:50 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4KFqbbo005740; Thu, 20 May 2004 11:52:38 -0400 (EDT) Message-ID: <40ACD429.9010209@dynamicsoft.com> Date: Thu, 20 May 2004 11:52:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Barany, Pete" CC: mmusic@ietf.org Subject: Re: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) References: <17D8F6DF3ED94D40BD607380866D9B7F010E27A1@NAEX01.na.qualcomm.com> In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F010E27A1@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It doesn't apply to 0:0:0:0:0:0:0:0. In other words, a v6 host shouldn't generate this as a technique for putting a call on hold (or for any other purpose). There is no defined behavior for how to react if you received such a thing. -Jonathan R. Barany, Pete wrote: > Hi, > > In Section 8.4 of RFC 3264 "An Offer/Answer Model with the Session > Description Protocol (SDP)", the following statement is made: > > -->BEGIN > > RFC 2543 [10] specified that placing a user on hold was accomplished > by setting the connection address to 0.0.0.0. Its usage for putting > a call on hold is no longer recommended, since it doesn't allow for > RTCP to be used with held streams, doesn't work with IPv6, and breaks > with connection oriented media. However, it can be useful in an > initial offer when the offerer knows it wants to use a particular set > of media streams and formats, but doesn't know the addresses and > ports at the time of the offer. Of course, when used, the port > number MUST NOT be zero, which would specify that the stream has been > disabled. An agent MUST be capable of receiving SDP with a > connection address of 0.0.0.0, in which case it means that neither > RTP nor RTCP should be sent to the peer. > > -->END > > Question: > The statement "An agent MUST be capable of receiving SDP with a > Connection address of 0.0.0.0, in which case it means that neither > RTP nor RTCP should be sent to the peer." > > Does this apply also to IPv6 (0:0:0:0:0:0:0:0, or in abbreviated > format ::)? There is some mention about putting a call on hold early > in the paragraph above and how this doesn't work for IPv6 ... > therefore, this is the cause of my confusion. Thnx. > > - Pete > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 20 12:58:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02114 for ; Thu, 20 May 2004 12:58:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqob-0007Y9-Cg for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 12:54:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGsfRQ029015 for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 12:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqfE-0004fV-Fu for mmusic-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:45:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00591 for ; Thu, 20 May 2004 12:44:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqfC-0004gW-Qr for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:44:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqeC-0004cg-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:43:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqdR-0004Ya-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:43:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqTd-0000YV-Oq; Thu, 20 May 2004 12:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQq0L-0006ge-M1 for mmusic@optimus.ietf.org; Thu, 20 May 2004 12:02:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27500 for ; Thu, 20 May 2004 12:02:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQq0K-0000xe-Bk for mmusic@ietf.org; Thu, 20 May 2004 12:02:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQpyw-0000mR-00 for mmusic@ietf.org; Thu, 20 May 2004 12:01:19 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1BQpy4-0000Zw-00 for mmusic@ietf.org; Thu, 20 May 2004 12:00:24 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4KFxiU9013740; Thu, 20 May 2004 08:59:45 -0700 (PDT) Received: from NAEXFE03.na.qualcomm.com (naexfe03.qualcomm.com [172.30.32.23]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4KFxgrY014448; Thu, 20 May 2004 08:59:42 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 08:59:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) Date: Thu, 20 May 2004 08:59:53 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F010E27A4@NAEX01.na.qualcomm.com> Thread-Topic: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) Thread-Index: AcQ+goT4iZ+rct/YTQ6WupQwJ2Yb5gAAMpbA From: "Barany, Pete" To: "Jonathan Rosenberg" Cc: X-OriginalArrivalTime: 20 May 2004 15:59:42.0357 (UTC) FILETIME=[76896450:01C43E83] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable OK. My next question is, why not? Is there/was there a particular technical reason why it doesn't apply to 0:0:0:0:0:0:0:0? Thnx. - Pete -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Thursday, May 20, 2004 8:52 AM To: Barany, Pete Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) It doesn't apply to 0:0:0:0:0:0:0:0. In other words, a v6 host shouldn't generate this as a technique for=20 putting a call on hold (or for any other purpose). There is no defined=20 behavior for how to react if you received such a thing. -Jonathan R. Barany, Pete wrote: > Hi, >=20 > In Section 8.4 of RFC 3264 "An Offer/Answer Model with the Session > Description Protocol (SDP)", the following statement is made: >=20 > -->BEGIN >=20 > RFC 2543 [10] specified that placing a user on hold was accomplished > by setting the connection address to 0.0.0.0. Its usage for putting > a call on hold is no longer recommended, since it doesn't allow for > RTCP to be used with held streams, doesn't work with IPv6, and breaks > with connection oriented media. However, it can be useful in an > initial offer when the offerer knows it wants to use a particular set > of media streams and formats, but doesn't know the addresses and > ports at the time of the offer. Of course, when used, the port > number MUST NOT be zero, which would specify that the stream has been > disabled. An agent MUST be capable of receiving SDP with a > connection address of 0.0.0.0, in which case it means that neither > RTP nor RTCP should be sent to the peer. >=20 > -->END >=20 > Question: > The statement "An agent MUST be capable of receiving SDP with a > Connection address of 0.0.0.0, in which case it means that neither > RTP nor RTCP should be sent to the peer." >=20 > Does this apply also to IPv6 (0:0:0:0:0:0:0:0, or in abbreviated > format ::)? There is some mention about putting a call on hold early > in the paragraph above and how this doesn't work for IPv6 ... > therefore, this is the cause of my confusion. Thnx. >=20 > - Pete >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 20 13:14:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03277 for ; Thu, 20 May 2004 13:14:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqqs-00027V-NB for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 12:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KGv2ki008141 for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 12:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqn1-0006kC-3k for mmusic-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:53:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01409 for ; Thu, 20 May 2004 12:52:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqmz-0005bR-Cq for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:53:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqlr-0005R2-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:51:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqkO-0005CF-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:50:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqUg-0001D8-3s; Thu, 20 May 2004 12:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQq6d-0000si-Ok for mmusic@optimus.ietf.org; Thu, 20 May 2004 12:09:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28239 for ; Thu, 20 May 2004 12:09:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQq6c-0001ge-CJ for mmusic@ietf.org; Thu, 20 May 2004 12:09:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQq5i-0001a5-00 for mmusic@ietf.org; Thu, 20 May 2004 12:08:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BQq4u-0001PU-00 for mmusic@ietf.org; Thu, 20 May 2004 12:07:28 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 May 2004 08:14:37 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4KG6uDe029971; Thu, 20 May 2004 09:06:56 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIQ34864; Thu, 20 May 2004 12:06:55 -0400 (EDT) Message-ID: <40ACD7A7.4060002@cisco.com> Date: Thu, 20 May 2004 12:07:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Barany, Pete" CC: mmusic@ietf.org Subject: Re: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) References: <17D8F6DF3ED94D40BD607380866D9B7F010E27A1@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Barany, Pete wrote: > > Question: > The statement "An agent MUST be capable of receiving SDP with a > Connection address of 0.0.0.0, in which case it means that neither > RTP nor RTCP should be sent to the peer." > > Does this apply also to IPv6 (0:0:0:0:0:0:0:0, or in abbreviated > format ::)? There is some mention about putting a call on hold early > in the paragraph above and how this doesn't work for IPv6 ... > therefore, this is the cause of my confusion. Thnx. It never said that, so I don't suppose you can assume it, even though I would expect most implementors would consider it a no-brainer to do this. OTOH, if you want to use this mechanism for hold, why not just use the IPv4 form? Even if you otherwise would use an IPv6 address, this doesn't have to. Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 20 13:17:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03574 for ; Thu, 20 May 2004 13:17:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQr36-0005R3-34 for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 13:09:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KH9eOs020889 for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 13:09:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqp5-0007hp-Ei for mmusic-web-archive@optimus.ietf.org; Thu, 20 May 2004 12:55:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01682 for ; Thu, 20 May 2004 12:55:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqp3-0005rh-Qa for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:55:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqo8-0005lm-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:54:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQqnU-0005fC-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 12:53:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqYU-000326-TR; Thu, 20 May 2004 12:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQqHn-0005Lp-EP for mmusic@optimus.ietf.org; Thu, 20 May 2004 12:20:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29094 for ; Thu, 20 May 2004 12:20:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQqHl-0002n5-Vs for mmusic@ietf.org; Thu, 20 May 2004 12:20:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQqGq-0002jf-00 for mmusic@ietf.org; Thu, 20 May 2004 12:19:49 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1BQqGB-0002cW-00 for mmusic@ietf.org; Thu, 20 May 2004 12:19:08 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4KGHNU9015384; Thu, 20 May 2004 09:17:24 -0700 (PDT) Received: from NAEXFE03.na.qualcomm.com (naexfe03.qualcomm.com [172.30.32.23]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4KGGerw017027; Thu, 20 May 2004 09:17:21 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 09:16:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) Date: Thu, 20 May 2004 09:17:07 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F010E27A5@NAEX01.na.qualcomm.com> Thread-Topic: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) Thread-Index: AcQ+hKI1h8AOeQTJTgisNZ7+AgY1VQAAK6aA From: "Barany, Pete" To: "Paul Kyzivat" Cc: X-OriginalArrivalTime: 20 May 2004 16:16:56.0397 (UTC) FILETIME=[DEDF5FD0:01C43E85] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I am more interested in using 0:0:0:0:0:0:0:0 for offer/answer (not 'hold'). Regarding your comment about using 0.0.0.0 (even if you will choose IPv6 later), the 'answerer' party might assume that the offerer wants IPv4 and will therefore answer with an IN IP4 in the 'c=3D' line? So I don't trust that idea all that much ... Was there a technical reason that 0:0:0:0:0:0:0:0 was not accounted for (for either 'hold' or 'offer/answer')? Thnx. - Pete -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Thursday, May 20, 2004 9:07 AM To: Barany, Pete Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) Barany, Pete wrote: >=20 > Question: > The statement "An agent MUST be capable of receiving SDP with a > Connection address of 0.0.0.0, in which case it means that neither > RTP nor RTCP should be sent to the peer." >=20 > Does this apply also to IPv6 (0:0:0:0:0:0:0:0, or in abbreviated > format ::)? There is some mention about putting a call on hold early > in the paragraph above and how this doesn't work for IPv6 ... > therefore, this is the cause of my confusion. Thnx. It never said that, so I don't suppose you can assume it, even though I=20 would expect most implementors would consider it a no-brainer to do this. OTOH, if you want to use this mechanism for hold, why not just use the=20 IPv4 form? Even if you otherwise would use an IPv6 address, this doesn't have to. Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu May 20 18:39:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03071 for ; Thu, 20 May 2004 18:39:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQwAL-0001zM-Uo for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 18:37:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KMbTND007644 for mmusic-archive@odin.ietf.org; Thu, 20 May 2004 18:37:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQw1O-0008Fg-UM for mmusic-web-archive@optimus.ietf.org; Thu, 20 May 2004 18:28:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02328 for ; Thu, 20 May 2004 18:28:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQw1M-0005te-0o for mmusic-web-archive@ietf.org; Thu, 20 May 2004 18:28:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQw0L-0005pG-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 18:27:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQvzr-0005ll-00 for mmusic-web-archive@ietf.org; Thu, 20 May 2004 18:26:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvoa-00038h-VU; Thu, 20 May 2004 18:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvhw-0007F4-37 for mmusic@optimus.ietf.org; Thu, 20 May 2004 18:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00402 for ; Thu, 20 May 2004 18:08:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQvhs-0004c3-TL for mmusic@ietf.org; Thu, 20 May 2004 18:08:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQvhG-0004ZB-00 for mmusic@ietf.org; Thu, 20 May 2004 18:07:26 -0400 Received: from netblock-66-159-221-206.dslextreme.com ([66.159.221.206] helo=firewall.trivee.org) by ietf-mx with esmtp (Exim 4.12) id 1BQvga-0004Sm-00 for mmusic@ietf.org; Thu, 20 May 2004 18:06:44 -0400 Received: from noir.crocodile.org (extern2.avistar.com [199.184.244.2]) by firewall.trivee.org (8.12.10/8.12.10) with ESMTP id i4KM6DNZ094368 for ; Thu, 20 May 2004 15:06:14 -0700 (PDT) (envelope-from trivee@noir.crocodile.org) Message-ID: <40AD2BD5.3030602@noir.crocodile.org> Date: Thu, 20 May 2004 15:06:13 -0700 From: Vladimir Vysotsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Reference audio level indication in SDP? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I'm not sure if this question is appropriate here, so please point me in the right direction if not. In our SIP/SDP-based product, we've encountered the need to send audio streams between platforms with significantly different mappings between digital audio amplitude and sound volume. Rather than implement some kind of automatic gain adjustment based on measuring incoming audio volume at the receiver/mixer, I'm thinking it would be more appropriate to use SDP to specify an amplitude reference of the sender, and have receivers adjust their audio mixing levels accordingly (this could work in both offer/answer and announcement scenarios). However, I couldn't find any definitions of a suitable SDP parameter. Does something like this exist, and if not, would somebody be interested in designing it? Vladimir _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri May 21 07:11:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24149 for ; Fri, 21 May 2004 07:11:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7tu-00006G-IY for mmusic-archive@odin.ietf.org; Fri, 21 May 2004 07:09:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LB9IcO000384 for mmusic-archive@odin.ietf.org; Fri, 21 May 2004 07:09:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7iT-0005JZ-UH for mmusic-web-archive@optimus.ietf.org; Fri, 21 May 2004 06:57:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23555 for ; Fri, 21 May 2004 06:57:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7iP-0006Qz-PL for mmusic-web-archive@ietf.org; Fri, 21 May 2004 06:57:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7hT-0006GO-00 for mmusic-web-archive@ietf.org; Fri, 21 May 2004 06:56:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR7gc-000659-00 for mmusic-web-archive@ietf.org; Fri, 21 May 2004 06:55:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7ZJ-0002cT-QI; Fri, 21 May 2004 06:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7JT-0006kF-PK for mmusic@optimus.ietf.org; Fri, 21 May 2004 06:31:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22304 for ; Fri, 21 May 2004 06:31:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7JP-0001jP-Q2 for mmusic@ietf.org; Fri, 21 May 2004 06:31:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7Ih-0001XX-00 for mmusic@ietf.org; Fri, 21 May 2004 06:30:51 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BR7Hk-00018i-00 for mmusic@ietf.org; Fri, 21 May 2004 06:29:52 -0400 Received: from mangole ([130.209.247.112]:65036) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-MD5:128) (Exim 4.04) id 1BR7HC-0007H6-00; Fri, 21 May 2004 11:29:18 +0100 From: Colin Perkins Organization: http://csperkins.org To: mmusic@ietf.org Subject: Re: [MMUSIC] WG last call: draft-ietf-mmusic-sdescriptions-04.txt Date: Fri, 21 May 2004 11:29:23 +0100 User-Agent: KMail/1.6.2 Cc: Joerg Ott References: <200405061533.LAA20435@ietf.org> <200405091559.27719.csp@csperkins.org> In-Reply-To: <200405091559.27719.csp@csperkins.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200405211129.23963.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This working group last call ends today. There have been no objections, so we will request the IESG consider this draft for publication as a Proposed Standard RFC. Colin On Sunday 09 May 2004 15:59, Colin Perkins wrote: > This is to announce a two-week working group last call on the SDP > Security Descriptions for Media Streams > (draft-ietf-mmusic-sdescriptions-04.txt). Please send any final comments > on this draft to the mailing list by 21st May 2004. If no substantive > comments are received by that time, we shall request the IESG consider > this for publication as a Proposed Standard RFC. > > The following technical changes have occurred since the previous version > of this draft, necessitating another working group last call: > > 1) Addition of a new FEC_KEY parameter to specify key(s) for a FEC > stream that is separate from the media stream itself (new Section > 5.3.5, updated grammar, and updated SRTP offer/answer rules as a > result). > 2) Removal of the "SPLIT" FEC mode parameter > 3) Addition of text to deal with changing IP-address and/or port > when updating the session (Section 6.1.4). > 4) Removed support for SRTP-specific use of sdescriptions outside > offer/answer (Section 6.2) as it had a problem with RTCP support. > > Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon May 24 01:33:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28706 for ; Mon, 24 May 2004 01:33:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7u6-0008Tp-TH for mmusic-archive@odin.ietf.org; Mon, 24 May 2004 01:21:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4O5LcJj032597 for mmusic-archive@odin.ietf.org; Mon, 24 May 2004 01:21:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7nt-0007ng-U7 for mmusic-web-archive@optimus.ietf.org; Mon, 24 May 2004 01:15:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27973 for ; Mon, 24 May 2004 01:15:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS7nq-00058h-RS for mmusic-web-archive@ietf.org; Mon, 24 May 2004 01:15:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS7mv-0004r7-00 for mmusic-web-archive@ietf.org; Mon, 24 May 2004 01:14:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BS7mK-0004Zv-00 for mmusic-web-archive@ietf.org; Mon, 24 May 2004 01:13:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7WO-0004It-Bp; Mon, 24 May 2004 00:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS7Uk-00041M-2L for mmusic@optimus.ietf.org; Mon, 24 May 2004 00:55:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26559 for ; Mon, 24 May 2004 00:55:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS7Uh-000712-9A for mmusic@ietf.org; Mon, 24 May 2004 00:55:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS7TZ-0006gd-00 for mmusic@ietf.org; Mon, 24 May 2004 00:54:13 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BS7T5-0006P4-00 for mmusic@ietf.org; Mon, 24 May 2004 00:53:43 -0400 Received: from dynamicsoft.com ([63.113.46.110]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4O4rObo007435; Mon, 24 May 2004 00:53:25 -0400 (EDT) Message-ID: <40B135ED.60201@dynamicsoft.com> Date: Sun, 23 May 2004 19:38:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Barany, Pete" CC: Paul Kyzivat , mmusic@ietf.org Subject: Re: [MMUSIC] Question about the use of 0.0.0.0 and 0:0:0:0:0:0:0:0 in RFC 3264 (Offer/Answer) References: <17D8F6DF3ED94D40BD607380866D9B7F010E27A5@NAEX01.na.qualcomm.com> In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F010E27A5@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Barany, Pete wrote: > I am more interested in using 0:0:0:0:0:0:0:0 for offer/answer (not > 'hold'). What is it you want to accomplish? The problem is that we were using an IP address to try and imply a property (don't send anything). Its a much better idea to explicitly indicate the desired property (don't send anything), which is what the a=inactive does. Thus, using IPv6 0:0:0:0:0:0:0:0 further propagates the usage of what turned out to be a bad design choice. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic