Subject: [Cellar] Conversation about a NON-IANA request in Matroska

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 10 Aug 2021 12:17:42 -0500

Hi, Murray, the backup expert reviewer for Media Types, and our responsible
AD,

Cellar is working on the Matroska specification, and one issue we've
tripped over is that Matrosks implementations have traditionally used
unregistered MIME types such as "video/x-matroska" and file extension
".mkv", which have never been registered in the Media Types registry, and
(for extra credit) use "x-dash" notation that someone is likely to ask us
to change, if we were registering something now.

Specifically, the media types mentioned in
https://github.com/ietf-wg-cellar/matroska-specification/pull/529/files
have been in use for up to 19 years, and the sense of the Github discussion
is that actually registering them now won't have much impact on anything.

(You should be tagged in that PR, and that's where most of the discussion
I've seen has happened)

And we'd prefer not to start that conversation during AD Evaluation, IETF
Last Call, or (especially not!) during IESG Evaluation and formal IANA
review.

As this work moves forward in the IETF stream, we wanted to ask, is this a
thing we should talk with you about, sooner rather than later?

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 18 Aug 2021 16:53:35 -0500

Hi, Murray,

Just following up - have you had an opportunity to think about this yet?

If you have questions, Cellar is having our monthly interim meeting next
Tuesday, and you are, of course, welcome to swing by!

Best,

Spencer

On Tue, Aug 10, 2021 at 12:17 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Hi, Murray, the backup expert reviewer for Media Types, and our
> responsible AD,
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Aug 2021 16:06:52 -0700

Hi there, sorry for the delay.

> Hi, Murray, the backup expert reviewer for Media Types, and our

You flatter me.

> thing we should talk with you about, sooner rather than later?

Well, glad you asked.

In the spirit of the media types registry, I'm inclined to say we'd rather
have something registered under what's perhaps a bit of a non-ideal name so
that people can interoperate from a common, registered reference, than not.
This is why the rules for the vendor tree are so loose.

So as your AD, I'd be prepared to argue in favor of registering the x-dash
name, and including a sentence or two about why we're making an exception
with respect to BCP 178 this time.  Of course, we can confirm with the
actual media type reviewers that I'm not crazy here.

-MSK

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Aug 2021 11:21:46 -0400

Murray S. Kucherawy <[email-masked]> wrote:
    > So as your AD, I'd be prepared to argue in favor of registering the
    > x-dash name, and including a sentence or two about why we're making an
    > exception with respect to BCP 178 this time.  Of course, we can confirm
    > with the actual media type reviewers that I'm not crazy here.

Could we register "dash" and "x-dash"?

Could we write something like:

Implementations MUST accept both in perpetuity.
(that's easy to implement, and it's an archive format, so disk files and
resource forks...)

Until 2025, implementations SHOULD use video/x-matroska when creating files.
After 2025, implementations SHOULD use video/matroska when creating files.

(or another year sufficiently far in the future)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2021 12:04:51 -0700

> Could we register "dash" and "x-dash"?

You could, but...

> (or another year sufficiently far in the future)

If you're going to register "x-dash" on the basis of indeterminate inertia,
I would argue the "dash" one isn't worth registering.

I would encourage something like:

- register "dash", indicating it is the current and the only officially
supported one
- register "x-dash", indicating that it's officially deprecated and new
implementations MUST NOT generate it
- indicate that for supporting legacy implementations, all implementations
SHOULD accept both

At some point in the future if/when you are convinced nothing generates
"x-dash" anymore, you could do an update that turns "x-dash" into an error.

-MSK

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Aug 2021 16:01:14 -0400

Murray S. Kucherawy <[email-masked]> wrote:
    >> Implementations MUST accept both in perpetuity.  (that's easy to
    >> implement, and it's an archive format, so disk files and resource
    >> forks...)
    >>
    >> Until 2025, implementations SHOULD use video/x-matroska when creating
    >> files.  After 2025, implementations SHOULD use video/matroska when
    >> creating files.
    >>

    > If you're going to register "x-dash" on the basis of indeterminate
    > inertia, I would argue the "dash" one isn't worth registering.

okay.

    > - register "x-dash", indicating that it's officially
    > deprecated and new implementations MUST NOT generate it

    > - indicate that
    > for supporting legacy implementations, all implementations SHOULD
    > accept both

    > "x-dash" anymore, you could do an update that turns "x-dash" into an

That's why I suggested a transition date, so that this process could be
essentially automatic.  Readers would have some time to catch up.

If readers will never catch up, then I agree, just go with "x-dash", although
it sets a weird precedent to me.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Aug 2021 14:14:16 -0700

What I'm worried about is that picking a date effectively sets a flag day.
Have we ever successfully asserted a flag day in a standards action before?

But then the IETF has no control over whether anyone adheres to it, making
it effectively arbitrary anyway.

-MSK

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Aug 2021 22:55:05 -0400

> Have we ever successfully asserted a flag day in a standards action before?

It's not a flag day.
We don't have to coordinate upgrades.
A flag day means that we have to change both senders and receivers.

All receivers/readers will understand both.
It's just that senders will start marking with the new one.

    > it effectively arbitrary anyway.

That's true.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 24 Aug 2021 14:43:13 +0200

Hi,

Given one of the goal on this Matroska specification is long time
preservation, that would seem odd to design something that renders
older systems incompatible with the current/new specifications. If any
of the MIME types we have in attachments were to become invalid all of
a sudden we wouldn't like it.

I updated the Pull Request to clean the IANA explanation to reflect
that the old names are known but should not be used, instead the new
names should be used.
https://github.com/ietf-wg-cellar/matroska-specification/pull/529

Le ven. 20 août 2021 à 04:55, Michael Richardson <[email-masked]> a écrit :
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Aug 2021 17:01:58 -0400

> a sudden we wouldn't like it.

That's not what I suggested.

I suggested that every reader would always accept both values.

But that, at some date in the future, writers would start using the new
values.  I suggested that the date be decided now in order to:
  a) establish a deadline for readers to get updated.
  b) allow writing software to gracefully transition without having to be updated.
  (of course, such software could also have an option)

We assume that the files are forever, but that the software that reads them
will get updated now and then.

In reality, the mime type doesn't really go anywhere specific unless the file
is being transfered over email or http.  On MAC, with HFS, the MIME type
might lookup a resource type which gets associated with the file.

But I suspect that one can associate two things with one resource, and I also
suspect (having really never coded for MacOS) that it doesn't take mime types
as input anyway.

---

From: Steve Lhomme <[email-masked]>
Date: Wed, 25 Aug 2021 09:03:42 +0200

Hi,

> That's not what I suggested.

Sorry for misinterpreting your words.

> suspect (having really never coded for MacOS) that it doesn't take mime types

I agree with that. But I have the same concern as Murray that a 
hardcoded deadline may not really work.

It also doesn't seem like how our RFCs are designed, where we have some 
legacy values that should not be used throughout the Matroska format. 
Then we would also need to set some deadline for these values not be 
allowed to be written.

In the end when we say it SHOULD NOT be used, it applies right away, not 
some date in the future. That's the same approach I took with the 
transition of MIME types. Just like updating muxers may take some time, 
updating web servers and UPNP servers to update they MIME database will 
take some time.