f26 to f26 cups sharing problem

I'm having a cups sharing issue in what should be a straightforward
situation: an existing f26 system (the client) trying to get a
remote printer from a freshy installed f26 system (the server).
cupsd.conf on the server is set to allow sharing in general
and of the desired printer in particular,
and the firewalls (server and client) have mdns and ipp-client ports open.
Both machines are on the same internal network (192.168.1.4 and 192.168.1.6)
and I can ssh between them just fine so the network is ok.

On the client side, "avahi-browse -a" shows the printer from the server
just fine:

    + enp9s0 IPv4 HP Deskjet D2500 series @ liberty             Internet
Printer     local
    + enp9s0 IPv4 HP Deskjet D2500 series @ liberty             _ipps._tcp
          local
    + enp9s0 IPv4 HP Deskjet D2500 series @ liberty             UNIX
Printer         local

However, "cups-browsed -v" has an issue:(running with cups-browsed.service
stopped for testing)

    Avahi Browser: NEW: service 'HP Deskjet D2500 series @ liberty' of
type '_ipp._tcp' in domain 'local'
    Avahi Browser: CACHE_EXHAUSTED
    Avahi Browser: ALL_FOR_NOW
    Avahi Browser: NEW: service 'HP Deskjet D2500 series @ liberty' of
type '_ipps._tcp' in domain 'local'
    Avahi Browser: CACHE_EXHAUSTED
    Avahi Browser: ALL_FOR_NOW
    Avahi-Resolver: Failed to resolve service 'HP Deskjet D2500 series @
liberty' of type '_ipp._tcp' in domain 'local': Timeout reached
    listening
    Avahi-Resolver: Failed to resolve service 'HP Deskjet D2500 series @
liberty' of type '_ipps._tcp' in domain 'local': Timeout reached

If I "systemctl restart cups.service" on the server, then retry the
browse, the
result is:

    Could not connect to the server liberty.local:631 for
Deskjet-D2500-series!

So it seems like the broadcast from the server is working
but for some reason the server is not allowing the clien
to get the additional information from port 631.
Port 631 (ipp-client) is allowed by the firewall,
and "systemctl stop firewalld"
on the server does not change the behavior.

The address "liberty.local:631" is suspect, as the server should be
liberty.localdomain,
but even adding liberty.local to /etc/hosts made no difference.

On the server, a netstat shows

Proto Recv-Q Send-Q Local Address           Foreign Address       State   
   PID/Program name
tcp        0      0 0.0.0.0:ipp             0.0.0.0:*             LISTEN  
   882/cupsd
tcp6       0      0 [::]:ipp                [::]:*                LISTEN  
   882/cupsd
udp        0      0 0.0.0.0:ipp             0.0.0.0:*                     
   938/cups-browsed

so it sure seems like the server is listening on the right port...
and this client has no problem connecting to a legacy f14 system.
any clues or suggestions?