Relative IRI-s section in the LPF document

[iherman]

I wonder whether the references and section should not rely on the WhatWG spec rather than the RFC-s. That is what most of the W3C specs do these days. Maybe more importantly, this is what is done in the WPUB §3.1.7; we should be consistent within a family of specifications.

I actually wonder whether we should not mostly refer to §3.1.7 above. We would then have one place in our specs where this could be amended if needed. The LPF spec would then slightly extend that section saying that the rules described there are for the relative URL-s for URL-s appearing in the manifest, but that same rules should apply to references among constituent files.

Note that the section refers to the base URI of the manifest; I think this is unnecessary. The fact that the manifest.jsonld file, if present, must appear in the Root Directory (which is already the case), plus the rules defined in the WPUB document covers that case. On the other hand, if there is an index.html file the author may decide to place the manifest file somewhere else (or embed it), in which case this paragraph is not relevant.

[llemeurfr]

I now find mention of URLs in the WP spec in 2.6.3.3. inside this section there are links to the whatwg spec. But there is also in 2.6.3.2.3 a reference "url" jumping to https://w3c.github.io/wpub/#bib-url, plus some direct links to https://url.spec.whatwg.org/#absolute-url-string in the spec.

What should we use in the LPF spec then? a link to WP 2.6.3.3, to a [url] in the bibliography section of the LPF spec or directly to https://url.spec.whatwg.org/#relative-url-string?

[iherman]

In my view, we should refer to 2.6.3.3., which also covers the way relative URIs are handled within embedded manifests, and leave it at that. If there are inconsistencies, the editors of WPUB should then be responsible:-)

[llemeurfr]

The WP spec speaks about URLs, the LPF spec about IRIs (like OCF did). IRIs are an interesting concept but only URLs are used in real life. I propose to be consistent here and use the term URL as in the WP spec.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: (1) deep link to WP, (2) raise an issue on absolutization in the canonicalization, and (3) discuss origin vs. packages (at F2F)
  View the transcript

  Relative IRI-s section in the LPF document
  Garth Conboy: https://github.com/w3c/pwpub/issues/37
  Laurent Le Meur: Next - 37 - proposed by Ivan. The rewriting of the section about IRI. Section 2.3. Ivan has proposed to rewrite something simple, and I proposed to remove IRI and use URL instead, even if IRI are valid - but no one is using it…
  … everyone understands a URL. Relative URLs would be the target language. There was a reference to RFC, but we removed it… I think the text that is now in 2.3 is sufficient in what we want to express.
  Ivan Herman: To make it easier, and Matt is on the call, we make a reference from the packaging document to wpub - because in wpub there is a longer description of this. There is also a reference with a longer comment in the reference to URLs in the HTML spec. There is a mess about this term and a longer description in the HTML spec at the end to say “we use URL which may include other uses” so it’s taken care of.
  … essentially what the web publication document does is say we won’t redefine the wheel - in that chain, the lpf document refers to the HTML one.
  Romain Deltour: for the record, the Web Pub section on URLs in the manifest: https://www.w3.org/TR/wpub/#value-url
  Romain Deltour: I was going to ask about what was meant about following the rules? This refers to the specific paragraph about URLs - in part 1 publication manifest. We should be more specific and link out.
  … the other point is that it leads to a question about web publications and the relationship to the manifest and canonical manifest (which is authoritative). In the canonical manifest, all the URLs are made absolute. So what we see are a serialization of a manifest.
  Benjamin Young: I was hoping someone was more qualified is available, but it takes us back to the IRI note - Japan and other cultures, less restricted to 26 characters, do use IRIs to represent their URLs. Whether that’s necessary in spec language is orthogonal, but we shouldn’t dismiss it…
  … it’s heavily used elsewhere, but maybe not where we are. Specifically - what processing and parsing algorithm, as there is a host of them. The HTML one is fine for what it is, but it assumes a browser context and in the case of an audiobook, may not come with the same constraint…
  Benjamin Young: URI 3986 https://tools.ietf.org/html/rfc3986
  Benjamin Young: which could introduce more things - so the URI spec might be better.
  Jun Gamou: In Japanese web, I believe using only URL is fine enough.
  Ivan Herman: https://www.w3.org/TR/html52/references.html#biblio-url
  Ivan Herman: I put in IRC a reference here. This is the normative reference. There is a reference to URL - then a very long note (somewhat unusual) about URL and all the various terms. I think as far as we are concerned, we should accept whatever the HTML spec does. The HTML spec is used in japan.
  … if it works for users in general, we should just say “this is what we do.”
  Garth Conboy: That seems sensible - does anyone have a different view?
  Ivan Herman: As far as I remember, this is what we refer to in the web publication document. And explicitly we can refer to this note. The LPF document shouldn’t point to anything more than what is done in the web publication doc.
  George Kerscher: this is for my lack of understanding - when we say absolute URL, we’re talking about www.something.com/whatever but when it’s in the package and unzipped, isn’t it necessary to use a relative URL in order to consume that file?
  Ivan Herman: This comes back to the question from Romain - a relative URL is relative to the canonical URL, which is doable. On the other hand, you might have an absolute URL which refers to a file that is relative. Both should be OK for a reading system.
  … this is not a perfect answer because the canonicalization gives absolute URLs - which might refer to the same area.
  Benjamin Young: This is in a package, distributed into a device with or without device - there are absolute URLs that are different than what the system will have locally. The system will not know that things map together…
  … a relative URL in a zip file would should relative items.
  … the related thing in JSON LD which could solve for this - it’s called @base and it’s a way to include in the JSON LD what you are relative to. This introduces a way to have all urls relative to a specific value - but then locally if that isn’t there, then the processing system isn’t there.
  … so it could also be used to turn the filesystem into a related url set…
  Nick Ruffilo: If we use the root - such as localhost/ and everything builds off that - wouldn’t URLs all be absolute? If items are relative - could there be an issue of accessing items outside of the file itself… Would the file URL base be the origin? So - could the file itself be considered similar to using a localhost server
  Brady Duga: It is dangerous to conflate “localhost” and opening a local file. In the first case, we are opening a file from a server that happens to have a well known ip address, and any file opened that way will have the same origin. In the second case, we have a local file that will have a different origin than other files opened the same way
  Ivan Herman: Let step back a few levels here - I think that it is correct what Romain said - that canonicalization requiring the absolutization of the URL may create problems here. Because the canonicalization is in fact a series of specs to make clear what the user agent has to do with the information…
  … there is nothing imposed there. I may propose that we raise an issue that the absolutization step should be removed from the canonicalization but maybe try to use what benjamin noted - so what Benjamin does is clear…
  … then a packaging environment can go happily. I still believe this is not something that should be defined by us. The lightweight packaging format should refer to the web publication - then the responsibility to properly describe it is in the web publication document.
  Romain Deltour: there is potentially another issue related to all that - which may not be resolved by removing absolutization. When it comes to obtaining a manifest, and the origin of the entry page. At some point we will have to modify the algorithm, or define the origin of the lightweight package.
  Laurent Le Meur: I don’t think we can define the origin within the package. it’s when the package is put somewhere and exposed - it’s up to the publisher/distributor to define the origin of the web publication. The package itself has no origin.
  Romain Deltour: I think we then have to define the rules how a user agent may or must define the origin of a package. These give a lot to the user agent, and unless we define it we will have interoperability issues.
  Ben: I wanted to continue what Romain said - the origin isn’t something the publisher decides, it’s the user agent. On the web, it’s related to where you hit the thing, but the origin is restricted to a space defined by the user agent. We have the origin spec to determine what to do with that.
  … in the case of something opened out of a zip file - there is a defined origin for that. Because zip file could be used within an android app and unpackaged - they are going to create their own origins, then create a space of null origin where it’s heavily (or un) restricted
  … and the developers need to know what they can/should do. We haven’t said that the manifests in the package are restricted to what is in the package - for example, it could bull in data from outside the package and from the web.
  Garth Conboy: We wanted to get through more, but not sure we can push through this.
  Dave Cramer: I wanted to emphasis what Romain and Benjamin just said - this is a problem we need to solve and is key to security. We can’t end up where there is not an origin and we have issues like in epub.
  Garth Conboy: Given that, can we say the changes made in LPF should point back to WP
  … Can we agree on this at this stage? That is where the LPF spec is in the current draft.
  Proposed resolution: LPF draft is okay as (with deep link added), additional issues to be raised in WP. (Garth Conboy)
  Laurent Le Meur: I can try to add a deep link to the proper section in the web specification - a link to 2.6.3.3 but I don’t really know the best way to do it. Maybe I would need some advice.
  Proposed resolution: LPF draft is okay as is (with deep link added to WP), additional issues to be raised in WP. (Garth Conboy)
  Romain Deltour: -0.5
  Nick Ruffilo: +1 to move language and table conversation
  Ric Wright: +1 to tabling. Too many questions
  Romain Deltour: (-0.5 because it’s likely that the origin issue will need to be addressed specifically in the LPF)
  Laurent Le Meur: in section 3 - maybe it would be there we express that the user agent exposes a package as a web application, it has to decide what the origin is of the web publication. It’s not an issue of web publication, but processing a package when it becomes a web publication…
  … so it’s related to packaging…
  Garth Conboy: There seems to be lots of votes for tabling for next week in Boston. Then we do need to have some time for F2F logistics
  Summary: (1) deep link to WP, (2) raise an issue on absolutization in the canonicalization, and (3) discuss origin vs. packages (Ivan Herman)
  Garth Conboy: +1
  Ivan Herman: I agree with Tabling - whatever semantics we use on it. Those items are the 3 that came up that we have an agreement on that we need to discuss.
  Romain Deltour: +1
  Ivan Herman: We will have to discuss origin VS packages. Not sure what document - I have no idea what should be put there yet. Maybe both should be separate issues?
  Proposed resolution: (1) deep link to WP, (2) raise an issue on absolutization in the canonicalization, and (3) discuss origin vs. packages (at F2F) (Garth Conboy)
  Garth Conboy: +1
  Ivan Herman: +1
  Laurent Le Meur: +1
  Garth Conboy: I’m turning your summary into a proposal - then we’ll revote
  Romain Deltour: +1
  Tim Cole: +1
  Nick Ruffilo: +1
  Joshua Pyle: +1
  Ric Wright: +1
  Garth Conboy: Do we have time for 1 more?
  Resolution #6: (1) deep link to WP, (2) raise an issue on absolutization in the canonicalization, and (3) discuss origin vs. packages (at F2F)
  

[llemeurfr]

draft updated via 68f698a77d567a75a216a10f63abc0948a734f55.

Open question about where to express issue with absolutization.