Update the IANA registrations

[iherman]

Just flagging this for the future: the current registration in §G.1 for the application/oebps-package+xml Media Type says

The Package Document and its related specifications are maintained and defined by the W3C’s EPUB 3 Community Group.

This may have to be updated to say instead:

The Package Document and its related specifications are maintained and defined by the World Wide Web Consortium (W3C).

Actually, this is exactly what §G.2 says for the application/epub.zip media type. Not sure why we have a discrepancy.

[iherman]

Also, for both cases, the Author/Change controller: entry should also be updated; they currently say:

The published specification is a work product of the World Wide Web Consortium’s EPUB 3 Community Group. W3C has change control over this specification.

It should simply say

World Wide Web Consortium (W3C).

[mattgarrish]

Is it normal to keep updating these "registrations" even though we never update the actual registrations?

[iherman]

even though we never update the actual registrations?

you mean the essence does not change only the maintainer? This is something I will have to check, but I believe that it should be doable, yes.

[mattgarrish]

No, the substance of these registrations does not match the IANA registry.

The package registration in IANA references RFC4839, which in turn references EPUB 2.0.1.

All there is for the OCF registration is IDPF and Bill McCoy as a reference.

We tweak these registrations for one reason or another every revision, but I'm curious what purpose it ultimately serves?

[iherman]

We tweak these registrations for one reason or another every revision, but I'm curious what purpose it ultimately serves?

To be very honest, I am not sure either. But we should keep them up-to-date nevertheless...

[mattgarrish]

But we should keep them up-to-date nevertheless...

That's fine, so long as we aren't creating new issues by not going back to IANA with these.

But we'll also need to change the specification references again, too, as they're talking about the Packages/OCF 3.2 specs. Could we perhaps use a link to the current spec and drop the specific sub-version number so that less (or no) tweaking is necessary each time?

[iherman]

Could we perhaps use a link to the current spec and drop the specific sub-version number so that less (or no) tweaking is necessary each time?

Yes

[mattgarrish]

As noted in #1403, these registrations also reference the linking registry. We'll have to return to fix those references once their new location is settled.

[mattgarrish]

I think this issue can be closed now. The links to the linking registry were replaced with a specific mention of EPUB CFI since that's all it was ever referring to (but since these are not part of the spec, it doesn't add a reference).

I believe the other issues you had with this were resolved, @iherman ?

[iherman]

I believe the other issues you had with this were resolved, @iherman ?

Yes.

[iherman]

But I am not sure we should close it. When we go to CR we may want to find a way to update the IANA registration text, and making it clear that we now 'own' this. Akin to the registration of a new media type. By leaving this issue open we remind ourselves that this should be done...

[iherman]

FYI, have submitted a request for an update of the two media types by email; let's see if IETF wants us to go through a more formal procedure.

[iherman]

FYI, have submitted a request for an update of the two media types by email; let's see if IETF wants us to go through a more formal procedure.

The formal response in IANA is here:

https://lists.w3.org/Archives/Public/public-epub-wg/2022Aug/0000.html

[iherman]

An answer has been sent to IANA after the merge of #2383, essentially using the text in the PR description.

[iherman]

Per https://lists.w3.org/Archives/Public/public-epub-wg/2022Aug/0008.html this issue can now be closed with a satisfactory conclusion...