Dick,
> On Sep 15, 2025, at 3:28 PM, Dick Hardt <dick.ha...@gmail.com> wrote:
>
> Would love to hear more about your interop experience with version numbers —
> are there a couple gotchas that come to mind?
[Note: This is a big rabbit hole because IPP has 26 years and supports several
billion clients/printers. I will try not to go too deep but let me know if you
want more details...]
The main thing is that when protocol versions are interoperable (i.e. the same
on-the-wire encoding/protocol) then you need other mechanisms to allow clients
to discover protocol features. For IPP that means allowing a client to query
metadata (in IPP the metadata is called "attributes", so the client sends a
Get-Printer-Attributes request to get back the capabilities and status of a
printer), and then the client can decide how best to communicate with the
printer (or give up...) The only time we really found versioning to be a
solution is when we needed to be certain that an extension to the IPP message
encoding was supported (IPP/2.0 requires "collection" value support, which is
optional for IPP/1.x).
IPP also has the notion of a "feature" which can group multiple optional
operations (endpoints in OAuth), attributes (key/value pairs), and
semantics/behaviors. For example, if a printer supports the IPP "cloud
printing" extensions, the client can discover this by querying the
"ipp-features-supported" printer attribute and looking for the keyword "infra"
(the nickname for the spec) rather than looking for all of the operations and
attributes required by the spec.
In addition to allowing clients and servers to discover capabilities, it is
important that an existing ("old") client be able to work with a "new" server,
and vice versa, assuming that the client and server support a common subset
necessary for interop. As a concrete example, the CUPS 2.5+ OAuth code
explicitly only supports an AS that provides either RFC 8414 or OIDC metadata,
and tailors its requests to use security features (PKCE, OIDC nonce, token
exchange, etc.) advertised in the metadata. Obviously, a client could be
written/configured to require specific features (as a local security policy),
just as they can be configured to only support certain AS
implementations/providers today.
________________________
Michael Sweet
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
