Historical exclusion of authentication for Get-Printer-Attributes

Michael Sweet via ipp <[email protected]>
Newsgroups gmane.ietf.ipp
Message-ID <[email protected]>
[This documents behavior that goes back to RFC 2566 - Internet Printing Protocol/1.0: Model and Semantics]


The Get-Printer-Attributes operation is unique in that it does not support authentication of any kind.  The primary reason for this is that it is needed for discovering the supported URIs, security, and authentication methods for the Printer via the "printer-uri-supported", "printer-xri-supported", "uri-authentication-supported", and "uri-security-supported" attributes.  A secondary reason is that the corresponding SNMP Printer MIB elements are likewise available without authentication.

Unfortunately, when we updated RFC 2911 (what became RFC 8011 and STD 92) we forgot to explicit call this out, instead relying on the historical omission of any "access rights" paragraph in the definition of the Get-Printer-Attributes operation.  All other operations in RFC 2566/2911/8011 provide (directly or indirectly) a statement about the users that are allowed to send the operation, whose identity comes from the "most authenticated" source.  While the Get-Printer-Attributes description is silent on this, every IPP implementation since IPP/1.0 has allowed Get-Printer-Attributes requests without authentication in order to allow Clients to discover Printers, and the major IPP-based driverless printing standards (AirPrint, IPP Everywhere, Mopria, Wi-Fi Direct Printing) all depend on it.

Several years ago we defined a new Get-User-Printer-Attributes operation that performs the same query as Get-Printer-Attributes but that explicitly allows authentication in order to filter Printer capabilities based on the most authenticated user identity and whatever policy is in effect on the Printer.


________________________
Michael Sweet

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEkIbDzcZsP1Y8+PQFvmfHXsgfMkQFAmHg28EACgkQvmfHXsgf
MkTeTQ/+JzIOk3GGv6D5Ccqxy2bdVF4qYJHWzFfgqt4tuySJWh4Yu8q2unKV+0Rh
3iqXyfgDZWA5AuhazaClaxbYl6CzVD4kEG6V9fsmIkmWeCkA+GtUTN5woG0G4WwB
inzB0Iwb1fFugzHAU3TaZUMpEJaiV4gjcn9qBEmyEwVQM0VM7WpQuxH1+Ff/tBNl
91Yzf8UWuZ1o7EV8J//dW30jVUXPpwXMiy1MS0d96lR6jgJNtp3Px5fEI47pZ46y
hWR+bRvz+4rpvRnscCY5DnxnuNFOARNitVWlRa7SfV2sZeCSmgq8cmFbEGUkr4Rj
20m5KJgUUOqXGXA6pfWQ1bx7/DTp8kRZaX7NFvIZSNBiYGH5PyOEUYCdzjva56xE
B/Od5qfamXQiJpI9kHPkptx55JUah31kaLxy4iOuRAAbHgPZk4TTKLUGZc/eKrV2
ZAlBBtbSfdPzaXYk+yyUQw58A/cpw5mQhFYd2pHEDiNMeIj36R99CgXKIX1KLfWt
MTCs+sHOwr6HktuWdufxARP2fl7eM4ZkgTe0Uo7F/uXnWu4ZDTXtdLF0LB1D2DGc
5RH+RJkMpXK0AWAfwDyIBToNXT4/WGeBOdDRIp13ovfpPEnOixeqg6zs322DPUp8
Kw9AmQd/ogagi+Gqf3eOmxMIDKenQf/0GwnHKqq/qmDGWOeWWLk=
=/PjM
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.