Re: Comments on draft-ietf-mmusic-sdp-directory-type-00.txt

Ross Finlayson <finlayson@live.com> Tue, 14 March 2000 23:07 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id PAA22374 for confctrl-outgoing; Tue, 14 Mar 2000 15:07:43 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id PAA22369 for <confctrl@zephyr.isi.edu>; Tue, 14 Mar 2000 15:07:40 -0800 (PST)
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA20620 for <confctrl@isi.edu>; Tue, 14 Mar 2000 15:07:49 -0800 (PST)
Received: from kaipara.live.com (mg-20425427-18.ricochet.net [204.254.27.18]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id PAA14956 for <confctrl@isi.edu>; Tue, 14 Mar 2000 15:06:06 -0800 (PST)
Message-Id: <4.3.1.20000314144928.00b9dd50@shell7.ba.best.com>
X-Sender: rsf@shell7.ba.best.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Tue, 14 Mar 2000 14:59:42 -0800
To: confctrl@ISI.EDU
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Comments on draft-ietf-mmusic-sdp-directory-type-00.txt
In-Reply-To: <200003122137.VAA08716@csperkins.demon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Colin,

Thanks for the comments.

>  - When defining RTP payload formats, the combination of the m= and
>    a=rtpmap lines in SDP to define a MIME type for the payload format.
>    This may imply that the use of m=directory is referencing a top level
>    MIME directory type, which is presumably not intended?

Good point.  I'm not a MIME expert - perhaps the format name should instead 
be "application/directory", i.e.,
         m=application/directory <port> SAP
??  Is this consistent with the use of MIME to specify other (existing) 
kinds of 'directory' - e.g., LDAP?  (I can imagine that in the future we 
might also want to allow for SDP descriptions that describe LDAP 
directories.)  Anyway, I'll make sure to raise this issue in Adelaide.

>   I suggest that text is added to state that sessions announced within a
>    directory SHOULD NOT be announced outside the time period specified in
>    the description of that directory, and SHOULD NOT be announced after a
>    deletion message has been received for the directory.

Yes, good point.  This, of course, is something that's true for any media 
type - e.g., participants should also stop sending to an audio/video 
sessions after their multicast address(es) have expired - but it's worth 
reemphasizing in the context of directory sessions.

         Ross.