From exim@www1.ietf.org Thu May 6 06:12:35 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 GAA02870 for ; Thu, 6 May 2004 06:12:34 -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-0006AB-D5 for rmt-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 i46AA205023686 for rmt-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 1BLfiM-0002lI-FJ for rmt-web-archive@optimus.ietf.org; Thu, 06 May 2004 06:02: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 GAA02487 for ; Thu, 6 May 2004 06:02: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 1BLfiI-0001bX-Pt for rmt-web-archive@ietf.org; Thu, 06 May 2004 06:02:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfhA-0001Ck-00 for rmt-web-archive@ietf.org; Thu, 06 May 2004 06:01:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLfgD-0000oS-00 for rmt-web-archive@ietf.org; Thu, 06 May 2004 06:00:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfbl-0000RS-CK; 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 1BLfTh-00055R-Ng for rmt@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 FAA01461 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-0003JG-9Y for rmt@ietf.org; Thu, 06 May 2004 05:47:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfSd-0002tu-00 for rmt@ietf.org; Thu, 06 May 2004 05:46:36 -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: [Rmt] SDP Session Description for FLUTE Sessions Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport 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. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From exim@www1.ietf.org Thu May 6 09:08:32 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 JAA10934 for ; Thu, 6 May 2004 09:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiXu-0003gc-Nb for rmt-archive@odin.ietf.org; Thu, 06 May 2004 09:04:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46D4EUl014161 for rmt-archive@odin.ietf.org; Thu, 6 May 2004 09:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiTV-0001zu-5n for rmt-web-archive@optimus.ietf.org; Thu, 06 May 2004 08:59: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 IAA10396 for ; Thu, 6 May 2004 08: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 1BLiTT-0001dD-T9 for rmt-web-archive@ietf.org; Thu, 06 May 2004 08:59:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiSU-0001Cj-00 for rmt-web-archive@ietf.org; Thu, 06 May 2004 08:58:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLiRO-0000XG-00 for rmt-web-archive@ietf.org; Thu, 06 May 2004 08:57:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLiJB-000723-Ux; 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 1BLiH9-0005kS-KR for rmt@optimus.ietf.org; Thu, 06 May 2004 08:46: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 IAA09695 for ; Thu, 6 May 2004 08:46: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 1BLiH8-00043Y-AY for rmt@ietf.org; Thu, 06 May 2004 08:46:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLiGD-0003d8-00 for rmt@ietf.org; Thu, 06 May 2004 08:45:57 -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 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 Subject: [Rmt] Re: [MMUSIC] SDP Session Description for FLUTE Sessions Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport 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/ _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From exim@www1.ietf.org Fri May 7 10:50:37 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 KAA28170 for ; Fri, 7 May 2004 10:50: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 1BM6Zc-0004N0-MB for rmt-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 i47Ehafn016794 for rmt-archive@odin.ietf.org; Fri, 7 May 2004 10:43:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM640-0006Xt-Ne for rmt-web-archive@optimus.ietf.org; Fri, 07 May 2004 10:10: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 KAA23683 for ; Fri, 7 May 2004 10:10: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 1BM63y-0004hl-HA for rmt-web-archive@ietf.org; Fri, 07 May 2004 10:10:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM62y-0004Ej-00 for rmt-web-archive@ietf.org; Fri, 07 May 2004 10:09:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BM61x-0003lE-00 for rmt-web-archive@ietf.org; Fri, 07 May 2004 10:08:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5td-0007Ow-Ew; Fri, 07 May 2004 10:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM2I2-0001gl-4h for rmt@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 GAA12485 for ; Fri, 7 May 2004 06:09:05 -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 1BM2Hy-0003gD-8O for rmt@ietf.org; Fri, 07 May 2004 06:09:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM2FW-0002zg-00 for rmt@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 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 Subject: [Rmt] RE: [MMUSIC] SDP Session Description for FLUTE Sessions Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport 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. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt