Subject: [apps-discuss] Various image/* media type drafts

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Nov 2014 15:34:56 -1000

Colleagues,

After the meeting today, I proposed that Sean combine all of his image/*
media type registrations into a single document.  Each registration should
be fairly short, just the basic template each time with a reference to the
defining document.

I concurred with Mark and others in the room who said he should just
register the "x-" subtypes as-is, paying appropriate homage to the X- BCP
and updated registrations BCP.

I suggest that such a consolidation draft would be eligible for a Call For
Adoption given the feeling in the room, which is to say that there was no
objection to APPSAWG processing of them when I asked.  I didn't want to
take up a bunch of slots (and do a bunch of WGLCs, LCs, AD Evaluations,
etc.) when combining the various proposals would be simpler, with other
work also proposed for the WG.

Is there any peril to proceeding under those guidelines?  If none, then
Sean can proceed to produce that at his convenience.

-MSK, co-chairin'

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Nov 2014 01:54:02 +0000

As one of the reviewers of the current docs, this sounds good to me.
-Dave

From: apps-discuss [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, November 10, 2014 3:35 PM
To: IETF Apps Discuss
Subject: [apps-discuss] Various image/* media type drafts

Colleagues,

After the meeting today, I proposed that Sean combine all of his image/* media type registrations into a single document.  Each registration should be fairly short, just the basic template each time with a reference to the defining document.

I concurred with Mark and others in the room who said he should just register the "x-" subtypes as-is, paying appropriate homage to the X- BCP and updated registrations BCP.
I suggest that such a consolidation draft would be eligible for a Call For Adoption given the feeling in the room, which is to say that there was no objection to APPSAWG processing of them when I asked.  I didn't want to take up a bunch of slots (and do a bunch of WGLCs, LCs, AD Evaluations, etc.) when combining the various proposals would be simpler, with other work also proposed for the WG.
Is there any peril to proceeding under those guidelines?  If none, then Sean can proceed to produce that at his convenience.
-MSK, co-chairin'

---

From: Sean Leonard <[email-masked]>
Date: Mon, 10 Nov 2014 15:56:36 -1000

Hi colleagues,

I wanted to both concur with what Murray said, and offer elaboration (which is somewhat contradictory).

I don’t mind combining the image registrations.

However there are three ways that the registered types could go:
#1 image/x-FOO only
#2 image/FOO, with image/x-FOO as deprecated aliases
#3 something else

Based on my understanding of this subject matter, my (experienced?) opinion is that #2 is the way to go.

Unlike say “application/x-www-form-urlencoded”, these image types are not quite as hard-coded into the Internet (specifically Web) infrastructure as one might think. Historically web browsers and HTML viewers have taken the image media type as a hint only, passing the stream to its all-purpose image processing library (“libpr0n”).

Of these three types, “image/bmp” has actually been used in practice. It was served as such by Apache software across the board until 2010, when in a bug report in TIKA <https://issues.apache.org/jira/browse/TIKA-555>, it was renamed to “image/x-ms-bmp” in that piece of software. But Apache httpd itself still serves “image/bmp”: <https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types>. Furthermore, the media type “image/bmp” has been baked into Windows for years, see HKEY_CLASSES_ROOT\Mime\Database\Content Type\image/bmp in your friendly local Windows build.

So at least for Windows Bitmaps, the shoe is on the other foot: it is arguably more harmful to register image/x-*** (even in deprecated alias types) compared to just saying image/bmp and being done with it. Maybe image/bmp was wrong at the time, but it’s the right position to be in now (and it’s compatible with the relevant BCPs).

As for the metafiles, if people are serving WMFs and EMFs in webpages for general consumption, we have a more serious issue than futzing with the label. Thus I don’t see the interoperability harm in standardizing image/wmf and image/emf…at least pending resolution of what Microsoft wants to do or recognize.

Cheers,

Sean

On Nov 10, 2014, at 3:34 PM, Murray S. Kucherawy <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave Thaler <[email-masked]>
Date: Tue, 11 Nov 2014 02:01:08 +0000

For wmf and emf, #1 is what I heard people arguing for, and I think is the best approach.

-Dave

> -----Original Message-----
> From: apps-discuss [mailto:[email-masked]] On Behalf Of Sean
> Leonard
> Sent: Monday, November 10, 2014 3:57 PM
> To: Murray S. Kucherawy
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] Various image/* media type drafts
> 
> Hi colleagues,
> 
> I don't mind combining the image registrations.
> 
> Unlike say "application/x-www-form-urlencoded", these image types are not
> quite as hard-coded into the Internet (specifically Web) infrastructure as one
> might think. Historically web browsers and HTML viewers have taken the
> image media type as a hint only, passing the stream to its all-purpose image
> processing library ("libpr0n").
> 
> Of these three types, "image/bmp" has actually been used in practice. It was
> served as such by Apache software across the board until 2010, when in a bug
> report in TIKA <https://issues.apache.org/jira/browse/TIKA-555>, it was
> renamed to "image/x-ms-bmp" in that piece of software. But Apache httpd
> itself still serves "image/bmp":
> <https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types>
> . Furthermore, the media type "image/bmp" has been baked into Windows
> for years, see HKEY_CLASSES_ROOT\Mime\Database\Content
> Type\image/bmp in your friendly local Windows build.
> 
> So at least for Windows Bitmaps, the shoe is on the other foot: it is arguably
> more harmful to register image/x-*** (even in deprecated alias types)
> compared to just saying image/bmp and being done with it. Maybe
> image/bmp was wrong at the time, but it's the right position to be in now
> (and it's compatible with the relevant BCPs).
> 
> As for the metafiles, if people are serving WMFs and EMFs in webpages for
> general consumption, we have a more serious issue than futzing with the
> label. Thus I don't see the interoperability harm in standardizing image/wmf
> and image/emf...at least pending resolution of what Microsoft wants to do or
> recognize.
> 
> Cheers,
> 
> Sean
> 
> media type registrations into a single document.  Each registration should be
> fairly short, just the basic template each time with a reference to the defining
> document.
> >
> register the "x-" subtypes as-is, paying appropriate homage to the X- BCP and
> updated registrations BCP.
> >
> objection to APPSAWG processing of them when I asked.  I didn't want to take
> up a bunch of slots (and do a bunch of WGLCs, LCs, AD Evaluations, etc.)
> when combining the various proposals would be simpler, with other work
> also proposed for the WG.
> >
> > Is there any peril to proceeding under those guidelines?  If none, then Sean
> can proceed to produce that at his convenience.
> >
> > -MSK, co-chairin'

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Nov 2014 16:14:29 -1000

> For wmf and emf, #1 is what I heard people arguing for, and I think is the

+1, and image/bmp for that one.  I don't think image/wmf and image/emf are
likely to see actual adoption at this point.

-MSK (presently hatless)

---

From: Douglas Otis <[email-masked]>
Date: Mon, 10 Nov 2014 18:43:09 -0800

On Nov 10, 2014, at 6:14 PM, Murray S. Kucherawy <[email-masked]> wrote:

> +1, and image/bmp for that one.  I don't think image/wmf and image/emf are likely to see actual adoption at this point.

Dear Murray,

Agreed.  Security issues related to wmf such as mice and codec redirects did not help.

Regards,
Douglas Otis

---

From: Sean Leonard <[email-masked]>
Date: Fri, 14 Nov 2014 06:00:54 -1000

> +1, and image/bmp for that one.  I don't think image/wmf and image/emf are likely to see actual adoption at this point.

I did an implementation survey to arrive at my position on this. It looks like image/wmf and image/emf are in the wild.

I would like to point out some flaws in this rationale for (or against) image/wmf and image/emf. Stuff gets adopted if people choose to adopt it. I wrote the drafts in significant part because I wanted to use the correct media types in software that I supervise, which includes e-mail clients.

I did not invent the MIME type names—I just used what is actually out there. There is software out there that uses image/wmf and image/emf (do a web search—you will find some). Microsoft Windows and Apache are not among them; however, should market adoption matter? What is the threshold of market success for this WG?

If we want to interoperate with these pieces of software, should image/emf and image/wmf be “Deprecated alias types”, while image/x-emf and image/x-wmf be the official types? That doesn’t make sense.

The combination of RFC 6838 [BCP 13] and RFC 6648 [BCP 178] suggest that x- is deprecated for new registrations, and when given a choice between x- and no x-, the no-x- option is the way to go. Unless there is a concrete interoperability problem, speculative statements about likelihood of adoption should not derail the non-prefixed approach. (Especially when the point is that an implementer is trying to adopt the non-x- way.)

Admittedly the draft does not address prevalence issues—if folks think that it should be addressed, I can add that to the next draft. Not clear if it should be in the registration template, or elsewhere.

When it comes to media types, we are in a regime where there are numerous formats that have multiple type names. I have a lot of experience with application/pkcs7-mime and application/x-pkcs7-mime (and /pkcs7-signature), for example.

With reference to Postel’s law, receivers should be prepared to accept multiple type names. We should give prospective guidance to senders to pick the best one, which from what I know of WMF and EMF, is probably image/wmf and image/emf rather than the x- versions.

With all this said, I am not resolutely opposed to making the x- versions the default. Yet as I said above, that means that the non x- versions would be “deprecated alias types” and that just does not seem to make sense.

Respectfully submitted,

Sean