Subject: video/vnd.avi and audio/vnd.wave media types
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Dec 21 08:28:53 2005

Hi,

  It seems http://www.iana.org/assignments/media-types/video/ and
http://www.iana.org/assignments/media-types/audio/ lack the types
for which RFC 2361 established the codec registry, video/vnd.avi
and audio/vnd.wave. I think they should be added with reference to
RFC 2361 (http://www.rfc-editor.org/rfc/rfc2361.txt).

regards,
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: chris at w3.org (Chris Lilley)
Date: Tue Dec 20 15:41:22 2005
Subject: Registration of media type image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Saturday, December 17, 2005, 12:35:12 AM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>With RFC 3023 as it stands, however, it has all the problems that the
>>TAG finding notes regarding inconsistency of dual metadata; in
>>consequence it was felt safer to omit the parameter. As RFC 3066
>>carefully describes a consistent handling of +xml media types where a
>>charset is omitted, this was not felt to be a problem.

BH> The idea of RFC 3023's +xml convention is that applications can consider
BH> resources labeled with such types XML and process them in a generic way
BH> even if the specific media type is not known to the application.

Yes, I am familiar with the concept.

BH> This is not guranteed if the rules for detecing the character
BH> encoding of image/ svg+xml resources are different from those for
BH> application/xml resources or other non-text/* +xml types.

They aren't. As the registration says,

      This has identical semantics to the application/xml media type in
      the case where the charset parameter is omitted, as specified in
      RFC3023 sections 8.9, 8.10 and 8.11.

Thus, any content labelled at image/svg+xml can be treated as
application/xml and its encoding reliably determined according to the
rules given in RFC 3023.

BH> If you want to say that the charset parameter is better not used for
BH> image/svg+xml resouces that's fine,

"Better not used" is wooly, and conflicts with RFC 3023 which STRONGLY
RECOMMENDS that it be used at all times. Thus, the only safe way was to
omit it altogether.

BH> defining or implying different
BH> encoding detection requirements for image/svg+xml resouces than what
BH> we have for application/xml is not, as that would make the types
BH> incompatible.

Its not different; its a subset.

Now, a revision of RFC 3023 that said what the TAG finding says, would
make this a lot less dangerous and adding a charset parameter might then
be possible.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Sat Dec 17 00:34:26 2005
Subject: Registration of media type image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>With RFC 3023 as it stands, however, it has all the problems that the
>TAG finding notes regarding inconsistency of dual metadata; in
>consequence it was felt safer to omit the parameter. As RFC 3066
>carefully describes a consistent handling of +xml media types where a
>charset is omitted, this was not felt to be a problem.

The idea of RFC 3023's +xml convention is that applications can consider
resources labeled with such types XML and process them in a generic way
even if the specific media type is not known to the application. This is
not guranteed if the rules for detecing the character encoding of image/
svg+xml resources are different from those for application/xml resources
or other non-text/* +xml types.

If you want to say that the charset parameter is better not used for
image/svg+xml resouces that's fine, defining or implying different
encoding detection requirements for image/svg+xml resouces than what
we have for application/xml is not, as that would make the types
incompatible.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Tue Dec 13 05:45:45 2005
From: michelle.cotton at icann.org (Michelle Cotton)
Date: Mon Dec 19 19:43:29 2005
Subject: FW: [[email-masked]: Re: Problem with IANA MIME media types
	registry]
Message-ID: <[email-masked]>

Bruce,

This has been fixed.  The index file was accidentally overwritten with the
application media types page.

Thank you for letting us know.

Best regards,

Michelle Cotton
IANA  

----- Forwarded message from Bruce Lilly <[email-masked]> -----

Date: Sun, 11 Dec 2005 10:42:22 -0500
Subject: Re: Problem with IANA MIME media types registry
From: Bruce Lilly <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
[email-masked]

On Sun December 11 2005 10:06, Allison Mankin wrote:
> Bruce, 
> 
> FYI, the other top-level media types are still there on their
> FTP site, so this looks like something went wrong with their web
> generating approach, whatever that is...
> 
> ftp://ftp.iana.org/assignments/media-types/
> 
> Allison
> 
> P.S.  I happened to have the FTP version on my radar.

Thanks for the information -- the index.html file at the ftp site
has a revision date of 23-Aug-2005, whereas the file served via
HTTP is dated 30-November-2005.  I would have expected the same file
to be served by both protocols, with index.html being the default
for HTTP.  That that is evidently not happening is yet another cause
for concern, as it means that different access methods yield
different registration information.  Possibly the IANA HTTP server
is sending the application data (only) instead of index.html.

I've taken the liberty of copying the lists and IANA to update the
information regarding the registry.

Best regards,
  Bruce Lilly

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

----- End forwarded message -----

-- 
Kent Crispin 
[email-masked]    p: +1 310 823 9358  f: +1 310 823 8649
[email-masked] SIP: [email-masked]

From: chris at w3.org (Chris Lilley)
Date: Fri Dec 16 11:52:42 2005
Subject: Registration of media type image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, December 16, 2005, 2:26:53 AM, MURATA wrote:

Chris>>    Optional parameters:
Chris>>           None
Chris>> 
Chris>>           The encoding of an SVG document shall be determined by the
Chris>>           XML encoding declaration. This has identical semantics to the
Chris>>           application/xml media type in the case where the charset
Chris>>           parameter is omitted, as specified in RFC3023 sections
Chris>>           8.9, 8.10 and 8.11.

MM> The W3C TAG finding "Internet Media Type registration, consistency of use"
MM> says:
MM>         We recommend that section 7.1 of [RFC3023] be amended to
MM>         something like the following:

MM>         The use of the charset parameter, when the charset is reliably
MM>         known and agrees with the encoding declaration, is RECOMMENDED,
MM>         since this information can be used by non-XML processors to
MM>         determine authoritatively the charset of the XML MIME entity.

MM> Chris is behind this TAG finding, and I agree.

To clarify - I am not the sole or even primary author of that TAG
finding, but I stand behind it as an ex member of the TAG.

However, i am delighted to hear you say that you support the wording in
the TAG finding and support it's incorporation into RFC 3066 bis.

MM> Chris and I are co-editors for RFC 3023 bis.

Yes.

Once we can have the language you quote above in RFC 3023bis, I
would be much happier with a charset parameter on image/svg+xml.

With RFC 3023 as it stands, however, it has all the problems that the
TAG finding notes regarding inconsistency of dual metadata; in
consequence it was felt safer to omit the parameter. As RFC 3066
carefully describes a consistent handling of +xml media types where a
charset is omitted, this was not felt to be a problem.

MM> So, why does thie media type omit the charset param? I think that it
MM> makes a lot of sense to do exactly what the W3C TAG finding says.

I think so too. If you could send me the XML  source of RFC 3066 bis,
then as co-editor I can add the text that you quoted above.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Wed Dec 14 10:15:45 2005
Subject: Review of DLS media type
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bruce,

Thanks for your review. Please see comments inline.

Bruce Lilly wrote:
> On Thu October 20 2005 04:14, Magnus Westerlund wrote:
>>I would like to request review of the DLS media type documented in:
>>http://www.ietf.org/internet-drafts/draft-westerlund-mime-dls-00.txt
> 
> 
> First, a registration should use the template specified in RFC 2048
> section 2.8 (to be replaced by draft-freed-media-type-reg in due
> course).  Ideally, the registration template specification (e.g.
> RFC 2048) would be listed as an informative reference; the reference
> to the template need not be normative, and indeed specifying a draft as
> a normative reference is guaranteed to delay publication as an RFC until
> such time as the referenced draft is published as an RFC.  In particular,
> the security considerations should appear in the registration template
> proper so that they are readily visible when the registration is
> viewed.  Security is a vital consideration, and implementers should not
> have to dig around in multiple documents for security considerations;
> moreover, as less-than-diligent implementers will not do so, the security
> considerations should be explicitly spelled out in the registration
> template.

As the template we have been using now is published as RFC 4288 (BCP 13) 
the only thing needed is to update the reference.

> 
> Second, the draft states:
>    The DLS format may contain audio, displayable text data, and modeling
>    parameters (a.k.a. articulation parameters). In addition, the DLS
>    format contains a so-called conditional chunk which is 'active' in
>    the sense that it affects the execution of a DLS file parser.
> If the format audio content is truly optional ("may contain"), then
> perhaps a subtype of the application top-level type (rather than audio)
> would be more appropriate, particularly as some application is necessary
> to interpret the format ("affects the execution of a DLS file parser").
> See the description of the audio top-level type in RFC 2046 section 4.3,
> as well as the description of the application type in section 4.5.  Note
> that unrecognized subtypes under both types are treated as
> application/octet-stream, so there is no advantage to be gained w.r.t.
> existing MIME type handlers by specifying audio rather than application.
> On the other hand, i.e. if audio content is always mandatory rather than
> optional, the description in the draft should be revised accordingly.

The purpose of the DLS file format is to carry and specify the audio 
waveforms to be used in the synthesizers when rendering a MIDI 
performance. To my knowledge the audio waveforms are optional but will 
be included in almost all DLS files. The reason the waveform are 
optional is that in some cases the articulation parameters are the 
desired way of affecting the synthesizers. Thus a DLS file is always 
intended for an general audio rendering application and thus fits the 
top media type of audio.

> 
> Third, surely there must be some interoperability considerations, else
> there would not be separate format specifications (see also the RFC 2046
> section 4.3 reference to a "general-purpose audio playing application --
> is there some such application which will handle the proposed media types
> as well as registered audio media types; if not, registration under the
> application top-level type rather than audio is strongly recommended).

The intended application is any audio player capable of rendering midi 
using DLS.

I don't understand your reasoning why any separate format would need to 
have an interoperability consideration. If you define new 
functionalities and therefore define a new format for carrying these 
functionalities then there are nothing previous to interoperate with 
other than units not-supporting the format. I think we today with the 
number of file formats that are existing that basic case of not 
supporting a specific format does not belong in each and everyone 
formats interoperability specification.

> 
> Finally, see the definition of Magic numbers in RFC 2048 section 2.2.9,
> paragraph labeled (1).  As the draft identifies a byte sequence which is
> always present and thus can be used to identify the content, the draft
> text
>       Magic number(s):                None. However, the ninth to
>                                       twelfth bytes of the file must
>                                       equal (in hexadecimal notation)
>                                       44, 4c, 53, and 20, respectively.
> is self-contradictory (removing "None. " would remove the contradiction).

Yes, I agree with removing "None".

Cheers

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: [email-masked]
>From [email-masked]  Fri Dec 16 02:26:53 2005
From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Fri Dec 16 03:25:37 2005
Subject: Registration of media type image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Chris>    Optional parameters:
Chris>           None
Chris> 
Chris>           The encoding of an SVG document shall be determined by the
Chris>           XML encoding declaration. This has identical semantics to the
Chris>           application/xml media type in the case where the charset
Chris>           parameter is omitted, as specified in RFC3023 sections
Chris>           8.9, 8.10 and 8.11.

The W3C TAG finding "Internet Media Type registration, consistency of use" 
says:
	We recommend that section 7.1 of [RFC3023] be amended to something like the following:

	The use of the charset parameter, when the charset is reliably
	known and agrees with the encoding declaration, is RECOMMENDED,
	since this information can be used by non-XML processors to
	determine authoritatively the charset of the XML MIME entity.

Chris is behind this TAG finding, and I agree.  Chris and I are
co-editors for RFC 3023 bis.  So, why does thie media type omit 
the charset param?  I think that it makes a lot of sense to do 
exactly what the W3C TAG finding says.

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: chris at w3.org (Chris Lilley)
Date: Tue Dec 13 22:48:55 2005
Subject: Problem with IANA MIME media types registry
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Monday, December 12, 2005, 3:58:40 PM, IANA wrote:

I> All,

I> I'll check on this today and see what needs to be done to get this fixed.

I think
http://www.iana.org/assignments/media-types/application/index.html
got uploaded to http://www.iana.org/assignments/media-types/index.html

I> Michelle Cotton
I> IANA
I>  

I> -----Original Message-----
I> From: Chris Lilley [mailto:[email-masked]] 
I> Sent: Monday, December 12, 2005 12:30 AM
I> To: Bruce Lilly
I> Cc: [email-masked]; [email-masked]; [email-masked];
I> [email-masked]
I> Subject: Re: Problem with IANA MIME media types registry

I> On Sunday, December 11, 2005, 3:39:58 PM, Bruce wrote:

BL>> [CC'd to IETF discussion list and ietf-types discussion list]

BL>> Hello,

BL>> Recent changes to the page at
BL>> http://www.iana.org/assignments/media-types/index.html
BL>> accessed via the link from the IANA Assigned numbers page 
BL>> http://www.iana.org/numbers.html#M
BL>> have rendered the registry of assigned media types useless.
BL>> Prior to the recent change, the media types registry listed the 
BL>> assigned MIME top-level media types, viz. application, audio, image, 
BL>> message, model, multipart, text, and video.  Since the change, only 
BL>> the application top-level type is listed (audio, image, message, 
BL>> model, multipart, text, and video have vanished without a trace)

I> Or rather, become unlinked. For example
I> http://www.iana.org/assignments/media-types/image/
I> is still there, just not linked anywhere.

I> I suspect its just an update glitch, but anyway....

BL>> and superfluous repetition of the application subtypes listed in 
BL>> http://www.iana.org/assignments/media-types/application
BL>> has appeared (these of course are not top-level media types).

BL>> Could you please investigate what has gone awry and regenerate a 
BL>> page that provides top-level media types.

I> I agree, stable URIs for media types are very much needed.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: mankin at psg.com (Allison Mankin)
Date: Mon Dec 12 19:44:35 2005
Subject: Transport Area requests Media Type review of draft-ietf-avt-ulp-14.txt
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the four proposed
new media types, intended for the IETF tree, which are in the document,
draft-ietf-avt-ulp-14.txt, intended for Proposed Standard.

The types are audio/ulpfec, video/ulpfec, text/ulpfec and application/ulpfec

This document takes as its normative base RFC 3555 and the now approved 
and operative updated Media Types Registration document, 
draft-freed-media-type-reg-05.txt

Please provide any comments before 5 January 2006.

Thanks,

Allison

From: iana at iana.org (IANA)
Date: Mon Dec 12 18:34:10 2005
Subject: Problem with IANA MIME media types registry
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

All,

I'll check on this today and see what needs to be done to get this fixed.

Michelle Cotton
IANA

-----Original Message-----
From: Chris Lilley [mailto:[email-masked]] 
Sent: Monday, December 12, 2005 12:30 AM
To: Bruce Lilly
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Problem with IANA MIME media types registry

On Sunday, December 11, 2005, 3:39:58 PM, Bruce wrote:

BL> [CC'd to IETF discussion list and ietf-types discussion list]

BL> Hello,

BL> Recent changes to the page at
BL> http://www.iana.org/assignments/media-types/index.html
BL> accessed via the link from the IANA Assigned numbers page 
BL> http://www.iana.org/numbers.html#M
BL> have rendered the registry of assigned media types useless.
BL> Prior to the recent change, the media types registry listed the 
BL> assigned MIME top-level media types, viz. application, audio, image, 
BL> message, model, multipart, text, and video.  Since the change, only 
BL> the application top-level type is listed (audio, image, message, 
BL> model, multipart, text, and video have vanished without a trace)

Or rather, become unlinked. For example
http://www.iana.org/assignments/media-types/image/
is still there, just not linked anywhere.

I suspect its just an update glitch, but anyway....

BL> and superfluous repetition of the application subtypes listed in 
BL> http://www.iana.org/assignments/media-types/application
BL> has appeared (these of course are not top-level media types).

BL> Could you please investigate what has gone awry and regenerate a 
BL> page that provides top-level media types.

I agree, stable URIs for media types are very much needed.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Mon Dec 12 10:26:28 2005
Subject: draft-hoschka-smil-media-type vs +xml
Message-ID: <[email-masked]>

Hi,

? http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-12.txt
is a bit old by now, but I don't think application/smil should be COMMON
as it does not use the +xml convention for XML media types. Instead, it
should be OBSOLETE and application/smil+xml, defined in the same draft,
should be used instead.

http://www.w3.org/TR/2005/PR-SMIL2-20050927/ only has application/smil
(which is not currently registered), it should use application/smil+xml
and point out that application/smil is obsolete, assuming that the +xml
version will be registered in the not too distant future.

regards,
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Mon Dec 12 11:19:29 2005
From: chris at w3.org (Chris Lilley)
Date: Mon Dec 12 11:18:43 2005
Subject: draft-hoschka-smil-media-type vs +xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Monday, December 12, 2005, 10:27:14 AM, Bjoern wrote:

BH> Hi,

BH> ?
BH> http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-12.txt
BH> is a bit old by now, but I don't think application/smil should be COMMON
BH> as it does not use the +xml convention for XML media types. Instead, it
BH> should be OBSOLETE and application/smil+xml, defined in the same draft,
BH> should be used instead.

BH> http://www.w3.org/TR/2005/PR-SMIL2-20050927/ only has application/smil
BH> (which is not currently registered), it should use application/smil+xml
BH> and point out that application/smil is obsolete, assuming that the +xml
BH> version will be registered in the not too distant future.

Thanks for spotting this, Bj?rn. I suspect it was copied over from SMIL
2.0 which predates the +xml convention. I agree that
application/smil+xml should be the preferred type and should be
registered.

SMIL editors, the procedure to follow is given at
http://www.w3.org/2002/06/registering-mediatype.html

(and is supposed to start at last call, by the way)

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: distobj at acm.org (Mark Baker)
Date: Thu Dec  8 16:38:45 2005
Subject: Registration of media type image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hey Chris,

On 12/7/05, Chris Lilley <[email-masked]> wrote:
>
>    Optional parameters:
>           None
>
>           The encoding of an SVG document shall be determined by the
>           XML encoding declaration. This has identical semantics to the
>           application/xml media type in the case where the charset
>           parameter is omitted, as specified in RFC3023 sections
>           8.9, 8.10 and 8.11.

Can I assume this section above was supposed to be a replacement for
the encoding section below?

>    Encoding considerations:
>           Same as for application/xml. See RFC3023, section 3.2.

>    Security considerations:
>           As with other XML types and as noted in RFC3023 section
>           10, repeated expansion of maliciously constructed XML
>           entities can be used to consume large amounts of memory,
>           which may cause XML processors in constrained environments to
>           fail.
>
>           SVG documents may be transmitted in compressed form using
>           gzip compression. For systems which employ MIME-like
>           mechanisms, such as HTTP, this is indicated by the
>           Content-Transfer-Encoding header; for systems which do not,
>           such as direct filesystem access, this is indicated by the
>           filename extension and by the Macintosh File Type Codes. In
>           addition, gzip compressed content is readily recognised by
>           the initial byte sequence as described in RFC1952 section
>           2.3.1.

I don't see how that's a security issue.  Seems more an encoding one to me.

On the topic of compression though, I had heard a while ago (back in
the "image/svg-xml" days) that compressed SVG is sometimes sent as
image/svg+xml.  Is that still (assuming it was ever) the case?  The
spec seems to make it clear that SVG is compressed via HTTP
compression.

>    Published specification:
>           This media type registration is extracted from Appendix M of
>           the SVG 1.2 Tiny specification.
>           http://www.w3.org/TR/SVGMobile12

There was no "Applications which used this media type" section.  I
think it would be useful to say that there are numerous
implementations which currently support this media type.

Also, you might want to mention - probably in "interoperability" -
that this same media type was also prescribed for use in the SVG 1.0
and 1.1 specs.  And if there are any backward compatibility issues
between 1.2 and those, you might want to say something about that.

Cheers,

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
>From [email-masked]  Sun Dec 11 15:39:58 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Dec 11 15:39:35 2005
Subject: Problem with IANA MIME media types registry
Message-ID: <[email-masked]>

[CC'd to IETF discussion list and ietf-types discussion list]

Hello,

Recent changes to the page at
http://www.iana.org/assignments/media-types/index.html
accessed via the link from the IANA Assigned numbers page
http://www.iana.org/numbers.html#M
have rendered the registry of assigned media types useless.
Prior to the recent change, the media types registry listed
the assigned MIME top-level media types, viz. application, audio,
image, message, model, multipart, text, and video.  Since the
change, only the application top-level type is listed (audio, image,
message, model, multipart, text, and video have vanished without
a trace) and superfluous repetition of the application subtypes
listed in
http://www.iana.org/assignments/media-types/application
has appeared (these of course are not top-level media types).

Could you please investigate what has gone awry and regenerate
a page that provides top-level media types.
>From [email-masked]  Sun Dec 11 16:26:30 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Dec 11 16:26:00 2005
Subject: Review of DLS media type
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu October 20 2005 04:14, Magnus Westerlund wrote:
> Hi,
> 
> I would like to request review of the DLS media type documented in:
> http://www.ietf.org/internet-drafts/draft-westerlund-mime-dls-00.txt
> 
> 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: [email-masked]

First, a registration should use the template specified in RFC 2048
section 2.8 (to be replaced by draft-freed-media-type-reg in due
course).  Ideally, the registration template specification (e.g.
RFC 2048) would be listed as an informative reference; the reference
to the template need not be normative, and indeed specifying a draft as
a normative reference is guaranteed to delay publication as an RFC until
such time as the referenced draft is published as an RFC.  In particular,
the security considerations should appear in the registration template
proper so that they are readily visible when the registration is
viewed.  Security is a vital consideration, and implementers should not
have to dig around in multiple documents for security considerations;
moreover, as less-than-diligent implementers will not do so, the security
considerations should be explicitly spelled out in the registration
template.

Second, the draft states:
   The DLS format may contain audio, displayable text data, and modeling
   parameters (a.k.a. articulation parameters). In addition, the DLS
   format contains a so-called conditional chunk which is 'active' in
   the sense that it affects the execution of a DLS file parser.
If the format audio content is truly optional ("may contain"), then
perhaps a subtype of the application top-level type (rather than audio)
would be more appropriate, particularly as some application is necessary
to interpret the format ("affects the execution of a DLS file parser").
See the description of the audio top-level type in RFC 2046 section 4.3,
as well as the description of the application type in section 4.5.  Note
that unrecognized subtypes under both types are treated as
application/octet-stream, so there is no advantage to be gained w.r.t.
existing MIME type handlers by specifying audio rather than application.
On the other hand, i.e. if audio content is always mandatory rather than
optional, the description in the draft should be revised accordingly.

Third, surely there must be some interoperability considerations, else
there would not be separate format specifications (see also the RFC 2046
section 4.3 reference to a "general-purpose audio playing application --
is there some such application which will handle the proposed media types
as well as registered audio media types; if not, registration under the
application top-level type rather than audio is strongly recommended).

Finally, see the definition of Magic numbers in RFC 2048 section 2.2.9,
paragraph labeled (1).  As the draft identifies a byte sequence which is
always present and thus can be used to identify the content, the draft
text
      Magic number(s):                None. However, the ninth to
                                      twelfth bytes of the file must
                                      equal (in hexadecimal notation)
                                      44, 4c, 53, and 20, respectively.
is self-contradictory (removing "None. " would remove the contradiction).
>From [email-masked]  Sun Dec 11 16:42:22 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Dec 11 16:42:00 2005
Subject: Problem with IANA MIME media types registry
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Sun December 11 2005 10:06, Allison Mankin wrote:
> Bruce, 
> 
> FYI, the other top-level media types are still there on their
> FTP site, so this looks like something went wrong with their web
> generating approach, whatever that is...
> 
> ftp://ftp.iana.org/assignments/media-types/
> 
> Allison
> 
> P.S.  I happened to have the FTP version on my radar.

Thanks for the information -- the index.html file at the ftp site
has a revision date of 23-Aug-2005, whereas the file served via
HTTP is dated 30-November-2005.  I would have expected the same file
to be served by both protocols, with index.html being the default
for HTTP.  That that is evidently not happening is yet another cause
for concern, as it means that different access methods yield
different registration information.  Possibly the IANA HTTP server
is sending the application data (only) instead of index.html.

I've taken the liberty of copying the lists and IANA to update the
information regarding the registry.

Best regards,
  Bruce Lilly
>From [email-masked]  Mon Dec 12 09:30:03 2005
From: chris at w3.org (Chris Lilley)
Date: Mon Dec 12 09:29:17 2005
Subject: Problem with IANA MIME media types registry
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Sunday, December 11, 2005, 3:39:58 PM, Bruce wrote:

BL> [CC'd to IETF discussion list and ietf-types discussion list]

BL> Hello,

BL> Recent changes to the page at
BL> http://www.iana.org/assignments/media-types/index.html
BL> accessed via the link from the IANA Assigned numbers page
BL> http://www.iana.org/numbers.html#M
BL> have rendered the registry of assigned media types useless.
BL> Prior to the recent change, the media types registry listed
BL> the assigned MIME top-level media types, viz. application, audio,
BL> image, message, model, multipart, text, and video.  Since the
BL> change, only the application top-level type is listed (audio, image,
BL> message, model, multipart, text, and video have vanished without
BL> a trace)

Or rather, become unlinked. For example
http://www.iana.org/assignments/media-types/image/
is still there, just not linked anywhere.

I suspect its just an update glitch, but anyway....

BL> and superfluous repetition of the application subtypes
BL> listed in
BL> http://www.iana.org/assignments/media-types/application
BL> has appeared (these of course are not top-level media types).

BL> Could you please investigate what has gone awry and regenerate
BL> a page that provides top-level media types.

I agree, stable URIs for media types are very much needed.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: chris at w3.org (Chris Lilley)
Date: Thu Dec  8 05:23:06 2005
Subject: Registration of media type image/svg+xml
Message-ID: <[email-masked]>

Hello ietf-types,

The SVG WG requests feedback on its standards tree media type
registration for image/svg+xml:

http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/mimereg.html

M.1 Introduction

   This appendix registers a new MIME media type, "image/svg+xml" in
   conformance with RegMedia and W3CRegMedia.
   http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt
   http://www.w3.org/2002/06/registering-mediatype.html

M.2 Registration of Media Type image/svg+xml

   MIME media type name:
          image

   MIME subtype name:
          svg+xml

   Required parameters:
          None.

   Optional parameters:
          None

          The encoding of an SVG document shall be determined by the
          XML encoding declaration. This has identical semantics to the
          application/xml media type in the case where the charset
          parameter is omitted, as specified in RFC3023 sections
          8.9, 8.10 and 8.11.

   Encoding considerations:
          Same as for application/xml. See RFC3023, section 3.2.

   Restrictions on usage:
          None

   Security considerations:
          As with other XML types and as noted in RFC3023 section
          10, repeated expansion of maliciously constructed XML
          entities can be used to consume large amounts of memory,
          which may cause XML processors in constrained environments to
          fail.

          SVG documents may be transmitted in compressed form using
          gzip compression. For systems which employ MIME-like
          mechanisms, such as HTTP, this is indicated by the
          Content-Transfer-Encoding header; for systems which do not,
          such as direct filesystem access, this is indicated by the
          filename extension and by the Macintosh File Type Codes. In
          addition, gzip compressed content is readily recognised by
          the initial byte sequence as described in RFC1952 section
          2.3.1.

          Several SVG elements may cause arbitrary URIs to be
          referenced. In this case, the security issues of RFC3986,
          section 7, should be considered.

          In common with HTML, SVG documents may reference external
          media such as images, audio, video, style sheets, and
          scripting languages. Scripting languages are executable
          content. In this case, the security considerations in the
          Media Type registrations for those formats shall apply.

          In addition, because of the extensibility features for SVG
          and of XML in general, it is possible that "image/svg+xml"
          may describe content that has security implications beyond
          those described here. However, if the processor follows only
          the normative semantics of this specification, this content
          will be outside the SVG namespace and shall be ignored. Only
          in the case where the processor recognizes and processes the
          additional content, or where further processing of that
          content is dispatched to other processors, would security
          issues potentially arise. And in that case, they would fall
          outside the domain of this registration document.

   Interoperability considerations:
          This specification describes processing semantics that
          dictate behavior that must be followed when dealing with,
          among other things, unrecognized elements and attributes,
          both in the SVG namespace and in other namespaces.

          Because SVG is extensible, conformant "image/svg+xml"
          processors must expect that content received is well-formed
          XML, but it cannot be guaranteed that the content is valid to
          a particular DTD or Schema or that the processor will
          recognize all of the elements and attributes in the document.

          SVG has a published Test Suite and associated implementation
          report showing which implementations passed which tests at
          the time of the report. This information is periodically
          updated as new tests are added or as implementations improve.

   Published specification:
          This media type registration is extracted from Appendix M of
          the SVG 1.2 Tiny specification.
          http://www.w3.org/TR/SVGMobile12

   Additional information:

   Person & email address to contact for further information:
          Dean Jackson, Chris Lilley ([email-masked]).

   Intended usage:
          COMMON

   Author/Change controller:
          The SVG specification is a work product of the World Wide Web
          Consortium's SVG Working Group. The W3C has change control
          over these specifications.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG