August 2004 - Ietf-types

Pre review of 3GPP MIME type for RTP payload format
by Magnus Westerlund 28 Oct '04

28 Oct '04

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 between 1 and 2^32. ContentID: The OMA DRM content ID [75] used to identify the content when establishing a crypto context. The value is an RFC 2396 [60] URI, which shall be quoted using <">. RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The value is an URI in accordance with RFC 2396 [60], which shall be quoted using <">. IVnonce: The value of this parameter is the nonce that forms the IV as specified by the crypto transform, encoded using Base 64 [69]. Optional parameters: SelectiveEncryption: Indicates if this stream is selectively encrypted. Allowed values are 0 (false) and 1 (true). If not present, selective encryption shall not be used. Please note that unless this indicator is integrity protected, it fulfils no purpose. Encoding considerations: This type is only defined for transfer via RTP (RFC 3550). Security considerations: See considerations raised in RTP RFC 3550 [9] and any applicable profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release 6, Annex K for comments on security issues. The main issues that exists are: - This RTP payload format only confidentiality protects the RTP payload, thus header information is leaked, similarly to SRTP. - The use of stream ciphers as AES CM and no integrity protection allows an attacker to purposefully attack the content of the encrypted RTP payload by switching individual bits. - The usage of selective encryption without integrity protection allows for an attacker to perform any replacements of complete RTP payloads and packets it desires. - The payload format makes the receiver vulnerable to denial of service attacks that inserts RTP packets into the stream, that the receiver then interprets as being encrypted thus wasting computational resources. To prevent this attack, authentication needs to be used. Interoperability considerations: Published specification: 3GPP TS 26.234, Release 6. Open Mobile Alliance DRM Content Format V2.0 Applications which use this media type: Third Generation Partnership Project (3GPP) Packet-switched Streaming Service (PSS) clients and servers, which supports the Open Mobile Alliance's specification of Digital Rights Management version 2.0. Additional information: Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A Person & email address to contact for further information: magnus.westerlund(a)ericsson.com Intended usage: Common Author/Change controller: 3GPP TSG SA ---- End of template --- Hope for comments within a week. Otherwise any changes within 3GPP will be more difficult. Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

3 6

Registration for application/gdiff
by Lisa Dusseault 16 Sep '04

16 Sep '04

I'm trying to register a MIME type officially for application/gdiff. This type was defined in a W3C NOTE several years ago: <http://www.w3.org/TR/NOTE-gdiff-19970901> That Note defines the MIME type but apparently the authors never registered the MIME type with IANA. Now we'd like to use gdiff in applications where we'd be using the MIME type so having it officially registered would be nice. For example: <http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-03.txt> (try -04 if -03 turns up not found) I submitted the registration through the IANA web form a couple weeks ago but haven't gotten a response other than the automated form submission response. Is this smoothly underway or is there anything else I need to or can optionally do to help this registration out? Thanks, Lisa

2 1

Request For Registration of Media Type
by Marc Clifton 16 Sep '04

16 Sep '04

2 1

draft-freed-mime-p4-04 is apparently superseded by..
by Jeff Hodges 05 Sep '04

05 Sep '04

draft-freed-mime-p4-05 http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt draft-freed-media-type-reg-01 http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt MartinD or whomever might want to update their very nice page.. How to Register a Media Type with IANA (for the IETF tree) http://www.w3.org/2002/06/registering-mediatype.html thanks, JeffH

4 4

RE: Pre review of 3GPP MIME type for RTP payload format
by Magnus Westerlund (KI/EAB) 02 Sep '04

02 Sep '04

Hi Larry, Comments below, prefixed with [mw]. -----Original Message----- From: Larry Masinter To: Magnus Westerlund (KI/EAB) Cc: ietf-types(a)iana.org Sent: 2004-08-16 08:37 Subject: RE: Pre review of 3GPP MIME type for RTP payload format > The problem is that the RTP payload format this defines is capable of > wrapping any other payload format. Yes, the 'application' is the 'application as a wrapping technology'. > As any other payload format > theoretically has any of the media types, this format needs to handle > all of the types. This isn't inconsistent with using 'application'. [mw] Yes, I would agree with you in the general context. However things are not this simple in the RTP usage domain. I will try to explain reasons why RTP payload formats that apply to different media types needs to be registered in multiple media types. [\mw] > So from my perspective, I don't see a problem with removing "Image" and > "application" from the registration. The other three are needed. I think we differ on the meaning of the top level media type. You imagine that you need to use 'image' when the body is an image, and I don't think it is necessary at all. [mw] The fact is that RTP and its signalling do require the registration in the applicable. For RTP there is a clear explanation in RFC 3550 why it is harmful to mix different media types in the same RTP session. Due to this reason also the signalling in SDP does not allow the mixing of multiple media types in the same RTP session. So due to the above restrictions one can not register an single application/rtp.enc.aes128 to secure all the different media top levels. [\mw] I think it is harmful to register multiple media types when one will do nicely. It isn't necessary that every MIME label be completely descriptive of the content, but just that the MIME label contain sufficient information to find the appropriate reciever. [mw] There is actuallly a good thing with registering in each media type for format that applies to one or all. That way one can ensure that a format actually is applicable to that media type. If one only register a single format, then there is not the same foral check that the usage for a certain meda type actually is applicable. For example the audio/RED mime type which we are now registering as text/RED when it has been checked that it is applicable. [\mw] And, since you can't do anything with the content without decrypting it, and leaking information about the content is a concern, why not just use 'application' all the time? Like with ZIP files or PDF files. [mw] In the RTP framework you are required to leak what media type in the signalling path anyway. You will need to secure the signalling path individually to the desired security level. I am sorry that the kinks of the RTP payload format MIME registrations procceduers was not worked out years ago. Today when we have several years of baggage, changing things are difficult. Please take a look at RFC 3555 whith outline the RTP MIME registration procedures. We do know that we will need to probably update this document when the new MIME registration rules are agreed on. [\mw] Cheers Magnus Westerlund

3 4

Re: Request for comments for Media Type registration ofapplication/ccxml+xml
by Al Gilman 31 Aug '04

31 Aug '04

At 3:03 PM +0900 7/28/04, Martin Duerst wrote: >At 13:05 04/07/27 -0700, RJ Auburn wrote: > >>On 07/21/2004 22:03, "Larry Masinter" <LMM(a)acm.org> wrote: >> >>> These comments are as much about the general "IETF MIME type >>> registration from W3C recommendation" as they are about this >>> particular registration: >> >> >>Martin: Would you be the person to handle/address the general issues? > >Yes. For everybody's information, RJ is following the procedure laid >out >Because he is the first to do so, this is a very good case to see >where we have to tweak that description. I have already made two >additions: >1) Added a sentence "Make sure that this part of the specification > is readable on its own, without the context of the specification." > [for further details, a good example is probably better than a > lot of explanations] >2) Added a sentence "To make it easier for your WG to track comments > on the Media Type section, you may cross-post the comments list > for your specification." > [I want to leave this to the group for the moment. They have to > show that they addressed comments to the IESG, so having that > documented in a last call table may have advantages and > disadvantages.] > >Also, I'm planning to add some pointers to examples to the above >description, once we have them. That should make it easier for >others to do this. > >> > Your translation from HTML to ASCII left out line breaks >>> before heading lines, which made your template hard >>> to read. >> >>If needed I can resubmit a nicer looking version. Let me know... > >I guess that can wait for the next time you send something anyway, >but I hope this will be soon. > >> >> Published specification: >>>> >>>> This media type registration is for CCXML documents as >>>> described by this specification. >>> >>> I'm not 100% sure if this is necessary, but I'd expect >>> if the template were to appear elsewhere to see >>> a bibliographic citation, e.g., >>> >>> "Voice Browser Call Control: CCXML Version 1.0", W3C >>> Working Draft, 30 April 2004, W3C, >>> >>> Is "this specification" (or the whole specification) precise >>> enough? In some other cases, a single W3C recommendation defines >>> many different data types. Perhaps it would be useful to >>> say, somewhere, e.g., that the MIME type refers to XML bodies that >>> conform to the DTD/Schema referenced in Appendix B and C and >>> interpreted by the rules in the cited specification. >> >> >>Pointing at the schema/dtd sections seems reasonable. How is this for text: >> >>Published specification: >> This media type registration is for XML bodies that >> conform to the DTD/Schema referenced in Appendix B and C and >> interpreted by the rules this specification > >'this specification' -> 'of this specification' > >> >> Person & email address to contact for further information: >>>> >>>> RJ Auburn, <rj(a)voxeo.com>. >>> >>> Should there be a W3C contact as well? >> >> >>Dave/Max/Martin: Thoughts? > >Adding the name of a staff contact or so might be a good idea. > >> >> Intended usage: >>>> >>>> COMMON >>>> Author/Change controller: >>>> >>>> The CCXML specification is a work product of the World Wide Web >>> Consortium's >>>> Voice Browser Working Group. The W3C has change control over these >>>> specifications. >>> >>> Or perhaps the W3C contact address should be listed here. >> >>Dave/Max/Martin: Thoughts? > >The W3C is 'on the Web', not at a particular physical location. >This kind of wording has been used in some previous registrations, >and should be okay. Actually, Martin, the W3C should come up with something better. This is a detail of the "life after Rec[ommendation status is achieved]" that I am not aware we have laid out adequately. There is a slight problem because the W3C has studiously avoided being a legal entity which could be identified in standard X.500 terms. Do you have a technical comment? W3C technical reports include email addresses where readers should send technical comments. </quote> The Consortium has also assiduously avoided promising to answer questions about its utterances, other than that one may post 'comments' in the above manner. Clearly a 'comment' alleging that there is an inconsistency in the provisions of a specification, if read and found to be accurate, may result in something being added to the errata for a document. I would suggest that the 'comments to' email address be included in the contact information provided in a MIME type registration request. As far as identifying The Consortium it should suffice to use the URI as identification in this context. It would be helpful, but probably not required by the IETF pro-formas, to also allude to the process for change control by a reference to the W3C Process Document identified Al >Regards, Martin.

1 0

MIME-type Review Request: draft-ietf-simple-event-list-05.txt
by Allison Mankin 30 Aug '04

30 Aug '04

This is a request for MIME-type review for this document http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt wherein is found the registration of application/rlmi+xml Please send comments to both the ietf-types list and the cc recipients listed on this message. Thank you, Allison

2 1

Re-Send: MIME-type Review Request: draft-ietf-simple-event-list-05.txt
by Allison Mankin 30 Aug '04

30 Aug '04

Trying this again, in case the first one did not go out ------- Forwarded Message Date: Mon, 30 Aug 2004 09:19:10 -0700 From: Allison Mankin <mankin(a)psg.com> To: ietf-types(a)alvestrand.no cc: "Ted Hardie" <hardie(a)qualcomm.com>, "Scott Hollenbeck" <sah(a)428cobrajet.net>, "Allison Mankin" <mankin(a)psg.com> This is a request for MIME-type review for this document http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt wherein is found the registration of application/rlmi+xml Please send comments to both the ietf-types list and the cc recipients listed on this message. Thank you, Allison ------- End of Forwarded Message

1 0

Re: Request for comments for Media Type registration ofapplication/ccxml+xml
by Al Gilman 30 Aug '04

30 Aug '04

At 3:03 PM +0900 7/28/04, Martin Duerst wrote: >At 13:05 04/07/27 -0700, RJ Auburn wrote: > >>On 07/21/2004 22:03, "Larry Masinter" <LMM(a)acm.org> wrote: >> >>> These comments are as much about the general "IETF MIME type >>> registration from W3C recommendation" as they are about this >>> particular registration: >> >> >>Martin: Would you be the person to handle/address the general issues? > >Yes. For everybody's information, RJ is following the procedure laid >out >Because he is the first to do so, this is a very good case to see >where we have to tweak that description. I have already made two >additions: >1) Added a sentence "Make sure that this part of the specification > is readable on its own, without the context of the specification." > [for further details, a good example is probably better than a > lot of explanations] >2) Added a sentence "To make it easier for your WG to track comments > on the Media Type section, you may cross-post the comments list > for your specification." > [I want to leave this to the group for the moment. They have to > show that they addressed comments to the IESG, so having that > documented in a last call table may have advantages and > disadvantages.] > >Also, I'm planning to add some pointers to examples to the above >description, once we have them. That should make it easier for >others to do this. > >> > Your translation from HTML to ASCII left out line breaks >>> before heading lines, which made your template hard >>> to read. >> >>If needed I can resubmit a nicer looking version. Let me know... > >I guess that can wait for the next time you send something anyway, >but I hope this will be soon. > >> >> Published specification: >>>> >>>> This media type registration is for CCXML documents as >>>> described by this specification. >>> >>> I'm not 100% sure if this is necessary, but I'd expect >>> if the template were to appear elsewhere to see >>> a bibliographic citation, e.g., >>> >>> "Voice Browser Call Control: CCXML Version 1.0", W3C >>> Working Draft, 30 April 2004, W3C, >>> >>> Is "this specification" (or the whole specification) precise >>> enough? In some other cases, a single W3C recommendation defines >>> many different data types. Perhaps it would be useful to >>> say, somewhere, e.g., that the MIME type refers to XML bodies that >>> conform to the DTD/Schema referenced in Appendix B and C and >>> interpreted by the rules in the cited specification. >> >> >>Pointing at the schema/dtd sections seems reasonable. How is this for text: >> >>Published specification: >> This media type registration is for XML bodies that >> conform to the DTD/Schema referenced in Appendix B and C and >> interpreted by the rules this specification > >'this specification' -> 'of this specification' > >> >> Person & email address to contact for further information: >>>> >>>> RJ Auburn, <rj(a)voxeo.com>. >>> >>> Should there be a W3C contact as well? >> >> >>Dave/Max/Martin: Thoughts? > >Adding the name of a staff contact or so might be a good idea. > >> >> Intended usage: >>>> >>>> COMMON >>>> Author/Change controller: >>>> >>>> The CCXML specification is a work product of the World Wide Web >>> Consortium's >>>> Voice Browser Working Group. The W3C has change control over these >>>> specifications. >>> >>> Or perhaps the W3C contact address should be listed here. >> >>Dave/Max/Martin: Thoughts? > >The W3C is 'on the Web', not at a particular physical location. >This kind of wording has been used in some previous registrations, >and should be okay. Actually, Martin, the W3C should come up with something better. This is a detail of the "life after Rec[ommendation status is achieved]" that I am not aware we have laid out adequately. There is a slight problem because the W3C has studiously avoided being a legal entity which could be identified in standard X.500 terms. Do you have a technical comment? W3C technical reports include email addresses where readers should send technical comments. </quote> The Consortium has also assiduously avoided promising to answer questions about its utterances, other than that one may post 'comments' in the above manner. Clearly a 'comment' alleging that there is an inconsistency in the provisions of a specification, if read and found to be accurate, may result in something being added to the errata for a document. I would suggest that the 'comments to' email address be included in the contact information provided in a MIME type registration request. As far as identifying The Consortium it should suffice to use the URI as identification in this context. It would be helpful, but probably not required by the IETF pro-formas, to also allude to the process for change control by a reference to the W3C Process Document identified Al >Regards, Martin.

1 0

Re: draft-freed-mime-p4-04 is apparently superseded by..
by Jeff.Hodges＠KingsMountain.com 27 Aug '04

27 Aug '04

> I didn't see a LAST CALL or a Protocol Action > > http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html According to Ned (I called him), this is indeed the case. He said he'd post an explanation here in the near future. JeffH > > -----Original Message----- > > From: ietf-types-bounces(a)alvestrand.no > > [mailto:ietf-types-bounces@alvestrand.no] On Behalf Of Jeff Hodges > > Sent: Saturday, August 21, 2004 12:10 PM > > To: IETF Types vetting list > > Subject: draft-freed-mime-p4-04 is apparently superseded by.. > > > > draft-freed-mime-p4-05 > > http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt > > > > draft-freed-media-type-reg-01 > > http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt > > > > > > MartinD or whomever might want to update their very nice page.. > > > > How to Register a Media Type with IANA (for the IETF tree) > > http://www.w3.org/2002/06/registering-mediatype.html > > > > > > thanks, > > > > JeffH > > > JeffH

1 0