Skip to main content

MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files
RFC 3839

Revision differences

Document history

Date Rev. By Action
2017-05-16
01 (System) Changed document authors from "David Singer" to "David Singer, Roberto Castagno"
2015-10-14
01 (System) Notify list changed from singer@apple.com, roberto.castagno@nokia.com, magnus.westerlund@ericsson.com to magnus.westerlund@ericsson.com, roberto.castagno@nokia.com
2012-08-22
01 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2010-03-28
01 Alexey Melnikov State Changes to Dead from AD Evaluation::External Party by Alexey Melnikov
2010-03-28
01 Alexey Melnikov I haven't heard anything from Magnus Westerlund, so moving this to Dead state.
2010-02-12
01 Alexey Melnikov Waiting for Magnus Westerlund to decide what to do with this RFC. Ideally, a draft obsoleting it should be published.
2009-11-18
01 Alexey Melnikov State Changes to AD Evaluation::External Party from Waiting for AD Go-Ahead by Alexey Melnikov
2009-10-15
01 Alexey Melnikov Removed from agenda for telechat - 2009-10-22 by Alexey Melnikov
2009-10-08
01 Alexey Melnikov Placed on agenda for telechat - 2009-10-22 by Alexey Melnikov
2009-10-08
01 Alexey Melnikov Note that the document is still in IETF LC till October 14th.
2009-09-22
01 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-09-22
01 Amy Vezza State Changes to In Last Call from Waiting for AD Go-Ahead by Amy Vezza
2009-09-18
01 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-09-17
01 Cindy Morgan State Changes to In Last Call from Waiting for AD Go-Ahead by Cindy Morgan
2009-09-16
01 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-09-16
01 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2009-09-16
01 Alexey Melnikov State Changes to Last Call Requested from AD Evaluation::External Party by Alexey Melnikov
2009-09-16
01 Alexey Melnikov Last Call was requested by Alexey Melnikov
2009-09-16
01 Alexey Melnikov [Note]: 'Magnus Westerlund has agreed to serve as the document shepherd.<br>Note that this document is obsoleted by 3GPP TS 26.244 V8.1.0.' added by Alexey Melnikov
2009-09-16
01 Alexey Melnikov [Note]: 'Magnus Westerlund has agreed to serve as the document shepherd<br>' added by Alexey Melnikov
2009-09-12
01 Alexey Melnikov State Changes to AD Evaluation::External Party from Publication Requested by Alexey Melnikov
2009-09-11
01 Alexey Melnikov Draft Added by Alexey Melnikov in state Publication Requested
2004-07-16
01 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2004-07-16
01 Amy Vezza [Note]: 'RFC 3839' added by Amy Vezza
2004-07-13
01 (System) RFC published
2004-05-26
01 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-05-20
01 Amy Vezza IESG state changed to Approved-announcement sent
2004-05-20
01 Amy Vezza IESG has approved the document
2004-05-20
01 Amy Vezza Closed "Approve" ballot
2004-05-19
01 Allison Mankin State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Allison Mankin
2004-05-19
01 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2004-05-19
01 Allison Mankin
Ted needed a slightly strong RFC Editor note - I slipped up and
forgot to forward the request for a bit.

>  "Ongoing work related …
Ted needed a slightly strong RFC Editor note - I slipped up and
forgot to forward the request for a bit.

>  "Ongoing work related to this registration may introduce
>  new optional parameters.  One example area of effort may
>  introduce a parameter that would allow for codecs
>  in use within the MIME type to be asserted and determined without
>  examination of the file.  Those with interests in the area
>  should monitor registrations for updates"

vs. his original

> There is ongoing work related to this registration which may
>introduce one or more optional parameters.  One area of
> concern
> is the receiver's ability to determine which codecs are in use
> without examination of the file.  Those with interests in the
> area should monitor registrations for updates to this
> registration.
2004-04-30
01 (System) Removed from agenda for telechat - 2004-04-29
2004-04-29
01 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-04-29
01 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Amy Vezza
2004-04-29
01 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2004-04-29
01 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2004-04-29
01 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-04-29
01 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-04-28
01 Jon Peterson [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Undefined by Jon Peterson
2004-04-28
01 Jon Peterson
[Ballot comment]
No further objection, but let me say I strongly support Ted's comment. There are already serious interoperability problems in the field with incompatible …
[Ballot comment]
No further objection, but let me say I strongly support Ted's comment. There are already serious interoperability problems in the field with incompatible codecs for 'voice clips' and so on in the MMS world. Having something at the MIME header level for this would be very valuable.
2004-04-28
01 Jon Peterson [Ballot Position Update] New position, Undefined, has been recorded for Jon Peterson by Jon Peterson
2004-04-28
01 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-04-28
01 Ted Hardie
[Ballot discuss]
I'm concerned in general about the use of "bucket" mime types that don't allow the receiver
to know much about the contents without …
[Ballot discuss]
I'm concerned in general about the use of "bucket" mime types that don't allow the receiver
to know much about the contents without actually downloading and examining it.  Randy
Gellens has been circulating a draft privately proposing that we add an optional "codecs"
parameter to these, allowing the sender to indicate the codecs present inside as useful
information for recipients/potential recipients.  I believe that he has circulated that
draft to one of the authors of this draft, but I have not been able to confirm the result.  I'd
like us to ask the draft authors if they would object to including such parameter or
work with them to see if we can get a forward pointer included if there is time pressure here.

Note that this is not the only pair of mime types that Randy's draft discusses, and that its
broader applicability may create a problem for timing.
2004-04-28
01 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2004-04-28
01 Russ Housley [Ballot comment]
Copyright has wrong year.
2004-04-28
01 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2004-04-28
01 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck
2004-04-28
01 Scott Hollenbeck
[Ballot comment]
Sections 3 uses "RFC XXXX" to refer to what seems to be the eventual RFC number for this document.  That's a bit confusing …
[Ballot comment]
Sections 3 uses "RFC XXXX" to refer to what seems to be the eventual RFC number for this document.  That's a bit confusing at first read -- I can't tell if the authors mean "this document", or some other RFC.  I think it would be clearer to say "see the Security Considerations (section 2) in RFC XXXX" in section 3, add a short RFC Editor note right there in section 3 (not section 5), and text should be added to the IANA Considerations section to let IANA know that the RFC number needed in section 3 is the one for this document.  Perhaps the text from section 5 could be moved to section 4 to make it obvious for the IANA.
2004-04-28
01 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to Undefined from No Objection by Scott Hollenbeck
2004-04-28
01 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck
2004-04-28
01 Scott Hollenbeck
[Ballot comment]
Sections 3 and 5 use "RFC XXXX" to refer to what seems to be the eventual RFC number for this document.  As used …
[Ballot comment]
Sections 3 and 5 use "RFC XXXX" to refer to what seems to be the eventual RFC number for this document.  As used in Section 3, that's a bit confusing -- I can't tell if the authors mean "this document", or some other RFC.  I think it would be clearer to say "see the Security Considerations (section 2) in this document" in section 3.  Section 5 could then simply be removed.
2004-04-28
01 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-04-27
01 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin
2004-04-27
01 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin
2004-04-27
01 Allison Mankin Ballot has been issued by Allison Mankin
2004-04-27
01 Allison Mankin Created "Approve" ballot
2004-04-22
01 Allison Mankin State Changes to IESG Evaluation from Waiting for Writeup by Allison Mankin
2004-04-22
01 Allison Mankin Placed on agenda for telechat - 2004-04-29 by Allison Mankin
2004-04-06
01 (System) State has been changed to Waiting for Writeup from In Last Call by system
2004-03-23
01 Allison Mankin
[Note]: 'Last Call request was turned back because the MIME subtypes audio/3gpp and video/3gpp are not media - asked author if 3GPP is willing to …
[Note]: 'Last Call request was turned back because the MIME subtypes audio/3gpp and video/3gpp are not media - asked author if 3GPP is willing to reconsider the design of these subtypes.  Need to review with Ned if there is a way to use the standards tree to help 3GPP, but this will have to wait till after the holidays.' has been cleared by Allison Mankin
2004-03-09
01 Amy Vezza Last call sent
2004-03-09
01 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-03-08
01 Allison Mankin Last Call was requested by Allison Mankin
2004-03-08
01 Allison Mankin State Changes to Last Call Requested from AD Evaluation::AD Followup by Allison Mankin
2004-03-08
01 (System) Ballot writeup text was added
2004-03-08
01 (System) Last call text was added
2004-03-08
01 (System) Ballot approval text was added
2003-12-24
01 Allison Mankin State Changes to AD Evaluation::AD Followup from AD Evaluation by Allison Mankin
2003-12-24
01 Allison Mankin
[Note]: 'Last Call request was turned back because the MIME subtypes audio/3gpp and video/3gpp are not media - asked author if 3GPP is willing to …
[Note]: 'Last Call request was turned back because the MIME subtypes audio/3gpp and video/3gpp are not media - asked author if 3GPP is willing to reconsider the design of these subtypes.  Need to review with Ned if there is a way to use the standards tree to help 3GPP, but this will have to wait till after the holidays.' added by Allison Mankin
2003-12-23
01 Allison Mankin State Changes to AD Evaluation from Publication Requested by Allison Mankin
2003-12-23
01 Allison Mankin
This spec is time-sensitive with 3GPP, but it raises technical concerns. 

AD comments sent to author, AVT chairs, Ned and Harald...

" At the time …
This spec is time-sensitive with 3GPP, but it raises technical concerns. 

AD comments sent to author, AVT chairs, Ned and Harald...

" At the time of writing, the 3GPP file format (3GP) can contain H.263 or MPEG-4 video;  and AMR Narrow-band  or AMR wide-band speech, or AAC audio;  and 3GPP timed text."


1. audio/3gpp, video/3gpp pointing off to other types - there is
  no analogy that I can see for this in all the other media
  types, where the sub-type is not an actual medium, but only an organizational classifier for disparate media.  Indeed, for disparate media which, other than timed text, already have MIME types for  their file formats.

2. the disparate media examples given include one that does not yet have stable documentation, timed text.  Moreover, timed text is likely to be slow in the IETF because of technical issues.  MIME Proposed Standards usually require solid documentation of the payload.

3. Because the file format is extensible outside of the review of the MIME registration, that is, what the sub-types cover can change without the conditions for change even being spelled out, any statements about security, for instance, on active content, are only I.O.U's, which is not at all in the spirit of our requirements.  The second quote shows  full awareness of this:

    ...

    The 3GPP file format may contain audio, video, and 
    displayable text  data.  There is currently no provision
    for 'active' elements (such as scripts) of any kind.

    ...

    3GPP files have an extensible structure, so that it is
  theoretically possible that metadata fields or media
  formats could be defined in the future which could be
  used to induce particular actions on the part of the
  recipient, thus presenting additional security risks, but
  this type of capability is currently not supported in
  the referenced specification.

I could go on, but let me stop and ask you if 3GPP has any
flexibility about their approach.
2003-12-23
01 Allison Mankin Area acronymn has been changed to tsv from gen
2003-12-23
01 Allison Mankin State Change Notice email list have been change to <singer@apple.com>, <mankin@psg.com> from
2003-09-12
01 Natalia Syracuse Draft Added by Natalia Syracuse
2003-09-11
01 (System) New version available: draft-singer-avt-3gpp-mime-01.txt
2003-08-19
00 (System) New version available: draft-singer-avt-3gpp-mime-00.txt