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

From: Colin Perkins <[email-masked]>
Date: Sun, 12 Mar 2000 16:37:37 -0500

Ross,

I have a couple of comments on the draft describing the "directory" SDP
media type.

 - 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?

   I wonder if this link between top-level MIME types and SDP m= lines has
   other effects? For example, SDP defines "data" and "control" as possible
   values for the m= line, which may also not map well onto the MIME space.

 - I'm concerned with the handling of directories which timeout or which
   have exceeded their advertised lifetime. In particular, I am concerned
   by section 7 of the draft, which states that "parties that advertise
   within directories should also participate in advertising the directory
   itself".

   One reason for limiting the lifetime specified in the t= field of the
   directory announcement is that the announcer of that directory knows
   that the address allocated to the directory has a limited lifetime.
   Thus, allowing other participants to announce a directory is useful for
   robustness, but may cause problems if they extend the lifetime of a
   directory without renewing any "lease" on the address used for that
   directory.

   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. 

Colin

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 14 Mar 2000 14:59:42 -0800

Colin,

Thanks for the comments.

>    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.

>    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.

---

From: Mark Handley <[email-masked]>
Date: Tue, 14 Mar 2000 17:09:16 -0800

>directories.)  Anyway, I'll make sure to raise this issue in Adelaide.

The SDP spec is unfortunately not internally consistent:

Page 17:
   o The first sub-field is the media type.  Currently defined media are
     "audio", "video", "application", "data" and "control", though this
     list may be extended as new communication modalities emerge (e.g.,
     telepresense).  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.

Page 36:
   "media" (eg, audio, video, application, data).

       Packetized media types, such as those used by RTP, share the
       namespace used by media types registry [RFC 2048] (i.e. "MIME
       types").  The list of valid media names is the set of top-level
       MIME content types.  The set of media is intended to be small and
       not to be extended except under rare circumstances.  (The MIME
       subtype corresponds to the "fmt" parameter below).

Thus the spec is probably incorrect in suggesting that "data" and
"control" are valid media types.  Anyone know if either of these are
in use?  They should probably be removed to go to draft standard.

The current choice of MIME types is:

  application,audio,image,message,model,multipart,text,video

None of these seem immediately appropriate for a session directory,
but the most obvious one is "application" with the subtype being
"sap".

If you really think "directory" is needed, you might want to raise
this issue by sending mail to the "[email-masked]" mailing list
to see if there's any agreement there.  Defining new top-level MIME
types can only be done via standards-track RFC.

Cheers,
	Mark