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

[Note]: 'Magnus Westerlund has agreed to serve as the document shepherd.
Note that this document is obsoleted by 3GPP TS 26.244 V8.1.0.' added by Alexey Melnikov

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.

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

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

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

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

[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

[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

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.