[uf-new] Separating File Content from File Format

Charles Iliya Krempeaux supercanadian at gmail.com
Fri Apr 6 14:07:34 PDT 2007

Hello Manu,

On 4/6/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> Charles Iliya Krempeaux wrote:
> > I don't think we are disagreeing.
> >
> > You are saying that it says we SHOULD NOT use them.  And I'm not arguing
> > that.
> >
> > But "SHOULD NOT" is NOT the same a "MUST NOT".
> Agreed. Although, I don't think I made myself clear in the last post to
> this thread. The following I see as a MUST NOT:
> "MIME implementations must ignore any parameters whose names they do not
> recognize."
> In other words, "Web browsers MUST NOT process parameters whose names
> they do not recognize". Parameter recognition is based on MIME-type,
> isn't it? Or am I missing something?

Again... we are not disagreeing here.  I am not arguing this.

This still does not stop people from serving resources (on the web)
using Content Type with non-registered Content Type parameters.

> > And therefore, despite the encouragement (from the spec) to NOT make
> > up your own Content Type parameters, you still could.  And if you did,
> > you would still be complying with the spec.
> Isn't this a slippery slope?

I think this was an intended path to extension.

Much like developers defining their own (HTML) class name, and
developers defining their own "x-" prefixed MIME types, and developers
defining their own XML namespaces.

> Remember, we're not just talking about one
> MIME-type here, we're talking about possibly adding 2-5 parameters for
> all of these MIME-types:
> audio/basic
> audio/mp4
> audio/mpeg
> audio/mpeg4-generic
> audio/ac3
> video/DV
> video/H264
> video/mp4
> video/mpeg
> video/quicktime
> video/vc1
> image/gif
> image/jpeg
> image/tiff
> image/png
> ---------------------------------------------------------------------
> Just to set up an alternative for discussion purposes. If we wanted to
> specify the following for a file (WARNING: Strawman ahead):
> type, audio-codec, audio-codec-sample-rate, video-codec-sample-rate,
> video-codec-bitrate, size-in-octets, URL
> We could then mark-up the following text in a uF:
> ----------------------------------------------------------------------
> We just went rock climbing at The Gorge in West Virginia. Here are two
> downloadable files of us doing Angels Arete:
>  The Gorge - DV   (54MB, PCM 48Khz audio, HD-VCR/1125-60 video)
>  The Gorge - MPEG (22MB, MP3 192Kbps audio, MPEG-2 video)
> ----------------------------------------------------------------------
> We could create a hFile uF like so:
> <div class="hFile">
>  <a type="video/DV" href="/angels_arete.dv">The Gorge - DV</a>
>   (<abbr class="size-in-octets" title="56623104">54MB</abbr>,
>    <span class="audio-codec">PCM</span>
>    <abbr class="audio-codec-sample-rate">48Khz</span> audio,
>    <span class="video-codec">HD-VCR/1125-60</span> video)
> </div>
> <div class="hFile">
>  <a type="video/mpeg" href="/angels_arete.mpg">The Gorge - MPEG</a>
>   (<abbr class="size-in-octets" title="23068672">22MB</abbr>,
>    <span class="audio-codec">PCM</span>
>    <abbr class="audio-codec-sample-rate">192Kbps</span> audio,
>    <span class="video-codec">MPEG-2</span> video)
> </div>
> ----------------------------------------------------------------------
> The argument for the first alternative, adding parameters to
> pre-existing MIME-Types, seems a bit shaky. The second alternative,
> adding classes, is based on a widely accepted standard.
> Which one is the better solution for describing file formats?

Well... 2nd choice... with the (HTML) class names... is definitely
more in tune with the Microformat way.

See ya

    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/

More information about the microformats-new mailing list