Subject: RE: [MMUSIC] And one more SDP-quiz question on protocol IDs

From: [email-masked]
Date: Thu, 29 Apr 2004 14:13:35 +0300

Thanks Magnus

One thing to make clear on the media type with FLUTE: I'm happy with anything that's simple and works. (I just want to check that the reasoning behind whatever media types are allowed for FLUTE usage are solid enough so we don't need to rake over the question many times.)

I Agree that "application" is the natural fit for "FLUTE applications". We do need to answer 2 questions though:
1. do we need to specify which media types are allowed? (if not, then we allow all)
2. do we need to exclude certain ones? (like the unregistered ones, and how does this impact the SDP spec?)

---   ---   ---   ---

A quick trawl through RFC2045 found me:

     type := discrete-type / composite-type
     discrete-type := "text" / "image" / "audio" / "video" /
                      "application" / extension-token
     composite-type := "message" / "multipart" / extension-token
     extension-token := ietf-token / x-token
     ietf-token := <An extension token defined by a
                    standards-track RFC and registered
                    with IANA.>
     x-token := <The two characters "X-" or "x-" followed, with
                 no intervening white space, by any token>

RFC2046 kindly explains these media types: "text", "image", "audio", "video", "application", "multipart" and "message".

I'm coming to the opinion that we can allow any of the media types in a FLUTE "m line". Naturally any impementation would have to adhere to the media type definitions: a FLUTE channel (given by an m line) would only deliver files of the described media type (to ensure no impact on multi-channel congestion control schemes, I supect this is practically the same as saying the media type will be the same for the whole session).

So this would mean:
* you may use the application type for any file typess delivered and rendered to the user by the FLUTE receiver
* you may use the audio type if only audio files are delivered and rendered to the user by the FLUTE receiver
* you may use the video type if only video files are delivered and rendered to the user by the FLUTE receiver
etc...

So, for all but the most specialised FLUTE implementations, we'd expect the "application" media type. This may be as much as needs to be said in a "SDP for FLUTE" I-D.

--- this draws a line under my comments on "one or many media types allowed" ---

The issue about allowing the use of "data" and "control" is that SDP defines them so their use would be expected, but IANA has not registered them. Any idea why on earth these are not registered? Since SDP makes it clear that it's minimal set is to be rarely extended, surely the use of data and control is totally fine with SDP, regardless of the IANA registration?

The issue about allowing the use of "message" and "multipart" is that SDP does not define them but IANA has them registered. sdp-new text makes it clear that no further RFC is needed for these existing MIME top level types to be used - but what is actually needed (anything?) is unclear. (This is more academic interest than me having a real need).

--- now on when "data" might be prefered over "applciation" ---

SDP gave me the impression that "application" is suitable where 'the receiver renders the content to the user directly' and "data" is suitable where 'the receiver does not directly render the content to the user' (e.g. where the FLUTE receiver and media player are seperate applications):
   ...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. 

So the example of "m=data..." was based on trying to do what the spec asks for (not on any strong preference) and was not intended to exculude "m=application...".

---   ---   ---   ---

Since the quantity of text may have made this unclear, here's the bottom line:
* Practically anything if fine for me, including "application" only
* I want strong arguments for the way we go so that we don't need to re-enter this issue

Cheers, Rod.

PS Yep, AVT was a typo for AVP - oops

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Thu, 29 Apr 2004 13:09:05 +0100

Rod,

Can you remind us, briefly, what sort of data is conveyed in a FLUTE 
session? If it's always a single data format, could we not simply 
mandate that the MIME type and sub-type are signalled in the SDP "m=" 
line as the <media> and <fmt> respectively?

Colin

On 29 Apr 2004, at 12:13, [email-masked] wrote:

> Thanks Magnus
>
> One thing to make clear on the media type with FLUTE: I'm happy with 
> anything that's simple and works. (I just want to check that the 
> reasoning behind whatever media types are allowed for FLUTE usage are 
> solid enough so we don't need to rake over the question many times.)
>
> I Agree that "application" is the natural fit for "FLUTE 
> applications". We do need to answer 2 questions though:
> RFC2046 kindly explains these media types: "text", "image", "audio", 
> "video", "application", "multipart" and "message".
>
> I'm coming to the opinion that we can allow any of the media types in 
> a FLUTE "m line". Naturally any impementation would have to adhere to 
> the media type definitions: a FLUTE channel (given by an m line) would 
> only deliver files of the described media type (to ensure no impact on 
> multi-channel congestion control schemes, I supect this is practically 
> the same as saying the media type will be the same for the whole 
> session).
>
> So this would mean:
> * you may use the application type for any file typess delivered and 
> rendered to the user by the FLUTE receiver
> * you may use the audio type if only audio files are delivered and 
> rendered to the user by the FLUTE receiver
> * you may use the video type if only video files are delivered and 
> rendered to the user by the FLUTE receiver
> etc...
>
> So, for all but the most specialised FLUTE implementations, we'd 
> expect the "application" media type. This may be as much as needs to 
> be said in a "SDP for FLUTE" I-D.
>
> The issue about allowing the use of "data" and "control" is that SDP 
> defines them so their use would be expected, but IANA has not 
> registered them. Any idea why on earth these are not registered? Since 
> SDP makes it clear that it's minimal set is to be rarely extended, 
> surely the use of data and control is totally fine with SDP, 
> regardless of the IANA registration?
>
> The issue about allowing the use of "message" and "multipart" is that 
> SDP does not define them but IANA has them registered. sdp-new text 
> makes it clear that no further RFC is needed for these existing MIME 
> top level types to be used - but what is actually needed (anything?) 
> is unclear. (This is more academic interest than me having a real 
> need).
>
> SDP gave me the impression that "application" is suitable where 'the 
> receiver renders the content to the user directly' and "data" is 
> suitable where 'the receiver does not directly render the content to 
> the user' (e.g. where the FLUTE receiver and media player are seperate 
> applications):
> So the example of "m=data..." was based on trying to do what the spec 
> asks for (not on any strong preference) and was not intended to 
> exculude "m=application...".
>
> ---   ---   ---   ---
>