This is a request for MIME-type review for this document: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-dsr-codecs-03.txt Please send comments to both the ietf-types list and the cc recipients listed on this message. Thank you, -Scott-
I'm forwarding this question to the IETF-types list since I'm not sure we have the experience to decide this in the AVT working grou. The question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it appropriate to register the format under the "video" or "text" top-level type? Colin Begin forwarded message: > From: "Jose Rey" <rey <at> panasonic.de> > Date: 5 August 2004 19:13:39 BST > To: "Colin Perkins" <csp <at> csperkins.org>, "IETF AVT WG" <avt <at> ietf.org> > Cc: Jan van der Meer <jan.vandermeer <at> philips.com>, Magnus Westerlund > <magnus.westerlund <at> ericsson.com>, Dave Singer <singer <at> apple.com>, > Yoshinori Matsui <matsui.yoshinori <at> jp.panasonic.com> > Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP and > Media Types) > > Colin, Magnus, all, > > I would like to take the opportunity to make a call for comments on > whether to registrate the 3GPP timed text payload format also under > the "text" top level type. Two observations: > > In the 3GPP Timed text format, the text strings in the payload itself > are encoded using UTF8 or UTF 16, which should be a sufficiently low > requirement. Of course, all the decoration and nice features such as > font/background color, scroll, hyperlinks, blinking text is lost. > Since the main target of timed text is exactly applications that do(Continue reading)
How about registering it in the "application" tree, under "vnd.3gpp"? You will already find some 3GPP registrations there. See for instance: http://www.iana.org/assignments/media-types/application/ Best regards, Olivier |-----Original Message----- |From: Colin Perkins | | |I'm forwarding this question to the IETF-types list since I'm not sure |we have the experience to decide this in the AVT working grou. The |question is about draft-ietf-avt-rtp-3gpp-timed-text-04.txt: is it |appropriate to register the format under the "video" or "text" |top-level type? | |Colin | | | |Begin forwarded message: | |> From: "Jose Rey" |> |> Colin, Magnus, all, |>(Continue reading)
[Please keep the AVT list as a cc, so the authors of the draft get a copy] The aim here is to register the media type for use in RTP sessions, which are negotiated using SIP. Registering it under "application" or "vnd.3gpp" would complicate the signalling, and it would be preferable from our point of view to register this under "text" or "video" (as has been done with other RTP payload formats). That said, I'm not sure how the vnd tree works, so there may be a good reason to register it there, and then work out how to change SIP and/or SDP to make use of it. Colin On 9 Aug 2004, at 16:28, Biot Olivier wrote: > How about registering it in the "application" tree, under "vnd.3gpp"? > You will already find some 3GPP registrations there. > > See for instance: > http://www.iana.org/assignments/media-types/application/ > > Best regards, > > Olivier > > |-----Original Message----- > |From: Colin Perkins > | > |(Continue reading)
Hi, As the RTP payload format is developed in IETF, rather than 3GPP I think the MIME type used to identify that RTP payload format belongs in the IETF tree. Especially as the vendor tree implies that the 3GPP has control over the registration and any updates, which I don't think is appropriate for this payload format. The question is if 3GPP timed text should be registered in video, text, or both. My reasoning behind actually registering in both media types, would if one had clear indications that both are appropriate for different usages of the RTP payload format. Cheers Magnus Colin Perkins wrote: > [Please keep the AVT list as a cc, so the authors of the draft get a copy] > > The aim here is to register the media type for use in RTP sessions, > which are negotiated using SIP. Registering it under "application" or > "vnd.3gpp" would complicate the signalling, and it would be preferable > from our point of view to register this under "text" or "video" (as has > been done with other RTP payload formats). > > That said, I'm not sure how the vnd tree works, so there may be a good > reason to register it there, and then work out how to change SIP and/or > SDP to make use of it.(Continue reading)
I think the document should explain why it is that it registers both application/smil and application/smil+xml with exactly the same meaning. I think the answer is likely that this was a mistake, that application/smil+xml is recommended, but that 'application/smil' is in use in some parts of the community already, and it was thought better to register it as a valid alias. But I'm not sure; I'm not even sure it's a good idea to do this. Perhaps we want to separate out 'recommended' practice (as you would find in an IESG approved document or a W3C 'Recommendation') from some other kind of registration, e.g., ask IANA to register 'application/smil' with a notation "MIME type used for what is officially registered as application/smil+xml'. > The definition is based on RFC3023 defining the use of the > "application/xml" media type [3]. Before using the "application/smil" > or "application/smil+xml" media type, implementors must thus be > familiar with [3]. As far as I can tell, [3] has nothing to say about 'application/smil'. > This parameter is meant to be used in MIME media type based content > negotiation (such as that done with the HTTP "Accept" header) to > negotiate for a variety of SMIL based languages. It is modelled after > the "profile" parameter in the application/xhtml+smil MIME type > registration [4], and is motivated by very similar considerations. Presumably you mean xhtml+xml, not xhtml+smil. Is there any(Continue reading)
Hi, I would like to have a pre registration request review of the below propsed MIME type for a RTP payload format. This registration request is intended to use the updated registration procedure based on specification available from other standards body. The specification that the registration belongs to can be found in the following 3GPP contribution: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip Which is the specification delta that included the RTP payload format defined within to the following specification: http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip The registration template for this looks like the following: ------------------------------------------------------------ MIME media type name: audio, video, text, application, image MIME subtype name: rtp.enc.aescm128 Required parameters: opt: The payload type number of the payload type contained in the encrypted payload. An integer value between 0-127. rate: The timestamp rate of this payload type, which shall be the same as that of the original payload type. This is an integer value(Continue reading)
On 12 Aug 2004, at 17:30, Jose Rey wrote: > Dave, Magnus > > --(Continue reading)cut-- >>> >>> As I said in my previous email, registering under 'text' top level >>> type would mean that the modifiers cannot be used. >> >> why is that true? does text/* only admit of plain text? so, for >> example, text/html would not be permitted either?? >> > > This is what I understand from the slides from Colin presented during > the > meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip, > "09-RTP-Media-Types.pdf"). Specially slide three where it says: > > ". In particular, it is expected that text media types are "to some > extent readable even without the software that interprets them" > - RFC 2046 > - This rule is derived from email client behaviour; want to pass the > message > to a dumb pager if there's no better display option" > > Colin or Magnus may please correct me if I got it wrong... The slides you quote are my interpretation of the traditional rules for media under the "text" top level type. As you know, there has been some discussion on relaxing these rules for media types with limited domain of applicability. The RTP Payload Format for 3GPP timed text might fall
Hi, We have detected a copy and paste error of the complete Appendix K in the first of the below references, and it has been replaced with the following version. http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040481.zip Cheers Magnus Magnus Westerlund wrote: > Hi, > > I would like to have a pre registration request review of the below > propsed MIME type for a RTP payload format. This registration request is > intended to use the updated registration procedure based on > specification available from other standards body. > > The specification that the registration belongs to can be found in the > following 3GPP contribution: > > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip > Which is the specification delta that included the RTP payload format > defined within to the following specification: > > http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip >(Continue reading)
RSS Feed1 | |
|---|---|
3 | |
4 | |
2 | |
28 | |
25 | |
1 | |
15 | |
22 | |
10 | |
18 | |
18 | |
5 | |
12 | |
13 | |
7 | |
11 | |
23 | |
30 | |
24 | |
35 | |
12 | |
5 | |
11 | |
10 | |
40 | |
5 | |
93 | |
29 | |
13 | |
8 | |
48 | |
1 | |
2 | |
4 | |
8 | |
17 | |
26 | |
25 | |
8 | |
6 | |
10 | |
11 | |
15 | |
14 | |
8 | |
19 | |
13 | |
1 | |
28 | |
10 | |
14 | |
15 | |
15 | |
1 | |
7 | |
8 | |
25 | |
22 | |
45 | |
6 | |
3 | |
10 | |
10 | |
3 | |
35 | |
56 | |
3 | |
5 | |
3 | |
6 | |
5 | |
1 | |
2 | |
10 | |
1 | |
4 | |
9 | |
29 | |
31 | |
25 | |
16 | |
3 | |
18 | |
12 | |
1 | |
10 | |
16 | |
32 | |
56 | |
40 | |
43 | |
34 | |
42 | |
34 | |
36 | |
53 | |
39 | |
64 | |
44 | |
29 | |
9 | |
32 | |
4 |
