All,
Continuing this thread concerning resource URIs and the Same Origin policy that is used in web browsers for this sort of thing:
1. Web Browsers support a HTTP extension called Cross-Origin Resource Sharing (CORS), which is documented here:
https://fetch.spec.whatwg.org/#http-extensions
The kicker is that this extension is used to allow PUT and POST requests - GET, HEAD, and OPTIONS requests are *not* limited in any way. So it doesn't look like CORS is a solution for IPP resources.
2. Sharing OAuth bearer tokens across domain names probably won't work in the general case, either, because the resource URI passed in the authorization request will be different...
Given these discoveries, I think we just need to reword the conformance requirements to be explicitly clear, something like:
4.2.6 Printer ICC Profiles, Icons, and Other URIs
URIs reported by the Proxy to the Infrastructure Printer in an Update-Output-Device-Attributes (section 5.10) request MUST be Public Internet Accessible, Network Accessible without credentials, or hosted by the Infrastructure Printer (with the same credentials) so that both the Infrastructure Printer and Client can access them. The following Printer attributes, if supported by the Proxy, MUST be reported with Public Internet Accessible, Network Accessible, or Infrastructure Printer hosted URIs: "printer-icc-profiles" ("profile-uri" member attribute), "printer-icons", "printer-more-info-manufacturer", and "printer-strings-uri".
In short: public Internet, private Intranet, or server-hosted using the same credentials.
Thoughts?
________________________
Michael Sweet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20240508/1fe628d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20240508/1fe628d6/attachment.sig>