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

[Mark Handley <[e-mail]>]

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

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 "[e-mail]" 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