A standard rel value for the primary entry page would be welcome

[llemeurfr]

The audiobook spec states (4.1) that the primary entry page, if present, should be included as a resource (if not one must find it in the default reading order).

Even if the manifest processing model makes no use of this link, it would be good to define a standard rel value for this link, let's say 'start' or 'entry'.

If we don't define it, and if the PEP and the ToC are in different resources, a processor treating a manifest could consider it as a supplemental resource for an audiobook -> display it to the user in a list of supplement content where it does not belong.

Note: If the PEP and ToC are in the same resource, a rel=contents will be sufficient for the processor, which will use this information for fetching the ToC.

[mattgarrish]

This is more of a packaging problem, isn't it? If you come through the web, you're going through the primary entry page as it has the only link to the manifest.

With LPF, you could have index.html with a manifest named whatever located wherever, or a manifest called publication.json with a primary entry page named whatever located wherever. I can see how the latter gets problematic.

Could it be solved by requiring in LPF that when there is a primary entry page it must be index.html in the root, likewise if there is a manifest it must be publication.json in the root? Is there a need to only sometimes have required naming? Flexibility in this case may just lead to confusion.

[llemeurfr]

On the Web, the PEP will effectively be found first, and the Manifest next. This does not solve the problem. Let's suppose the manifest is external to the PEP and a back link to the PEP is present as a resource in the manifest: this is what 4.1 is about.
The processor has parsed the PEP, fetched and parsed the Manifest; it find a link to an html resource, but does not find any rel associated: what is it supposed to do with this resource? Because such resources may be supplemental content, the processor may decide to present it as an "attachment"; but it's not a normal attachment. A specific rel would help the processor decide how to deal with this resource.
Note: Processors won't store the URL of the PEP so that they can identify it when dealing with resources in the manifest. We can't count on that.

Re. LPF, it is true that if there is no publication.json (manifest) in the package, but an index.html (PEP) resource is present, the processor will look into the PEP to find the manifest. And also true that if there is a publication.json in the package but no index.html, a PEP may be hidden somewhere in the package. In this second case, nothing indicates that one of the resources in the manifest is a PEP; there also a specific rel would do the trick.

[wareid]

We will address this issue in the maintenance group, if still required.