Re: [Hls-interest] File extension and MIME-Type for an HLS encryption key

My head says that ".key" is what I've seen the most, however, for a
standards document, I think picking something that will "do the right
thing" by default is better.

Therefore I propose ".bin" as the extension.

Reasoning below.

---

Both Apache and Nginx register ".bin" as associated with
application/octet-stream, that so far there has been a consensus should be
the MIME type.

http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
https://github.com/nginx/nginx/blob/master/conf/mime.types

---

Go uses the same definition files for mimes if they exist on Unix.

https://golang.org/src/mime/type_unix.go

On Windows, it falls back to the registry.

Caddy (popular HTTP server written in Go) utilizes the standard library
"mime" package, and currently doesn't set a Content-Type if one doesn't
match, but has a comment to potentially default to application/octet-stream.
https://github.com/caddyserver/caddy/blob/191dc86f9e40c12517a133cf2181631c9adec791/modules/caddyhttp/fileserver/staticfiles.go#L321-L331

---

Node is a little more difficult to pin down, but the Connect middleware
used by Express, probably the most popular HTTP server for Node, defers to
"mime-db" package, which is based on the Apache and Nginx mime type pages
above.

On Thu, Jul 1, 2021 at 1:21 PM Roger Pantos <rpantos=
40apple.com@dmarc.ietf.org> wrote:

>
>
> On Jun 29, 2021, at 9:02 AM, Law, Will <wilaw=40akamai.com@dmarc.ietf.org>
> wrote:
>
> Is there any consensus on what the file extension and MIME-Type should be
> for an encryption key delivered to a HLS  player? The spec defines no
> constraints on this question.
>
> The DASH IF is standardizing an Ingest Specification which covers the
> ingest of CMAF-based content in both HLS and DASH formats. We’ll likely
> choose ‘.key’ as the file extension and are considering
> ‘application/octet-stream’ as the Mime-Type in the absence of objections.
> Asking here in case there is a de-facto industry standard already in use,
> or opinion on whether we should go to the length of registering a new
> ‘encryption key’ MIME-type with IANA.
>
>
> For what it's worth, I haven't seen reports of the decryption key filename
> extension or MIME type causing interop issues, so I don't have a strong
> feeling about this one way or the other.
>
> I'm not aware of a common industry practice in this area. As Valentijn
> noted, .key is used by Apple's Keynote app so that's a consideration. Maybe
> .lic for license?
>
> I think that application/octet-stream is fine.
>
>
> Roger.
>
> --
> Hls-interest mailing list
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest
>

-- 
Jamie Stackhouse
DEVELOPER, REDSPACE
902 444.3490 x3170 <+19024443490>
redspace.com <https://www.redspace.com/> / Linkedin
<https://www.linkedin.com/company/333844?trk=vsrp_companies_cluster_name&trkInfo=VSRPsearchId%3A143433421433805150136%2CVSRPtargetId%3A333844%2CVSRPcmpt%3Acompanies_cluster>
 / Facebook <https://www.facebook.com/theREDspaceca> / Twitter
<https://twitter.com/theredspace>