Przez długi czas wielu programistów było głęboko nieusatysfakcjonowanych starym dobrym LPD. Rozpoczęto kilka projektów, mających usprawnić drukowanie: LPRng jest najbardziej znanym przykładem. Inne to PDQ, PPR, PLP, GNUlpr i RLPR. Ale żaden z tych nowych programów nie był postrzegany jako „złoty strzał”; wiele z nich do tych samych specyfikacji LPD dodawało tylko kilka (lub więcej) nowych rozszerzeń, które ponownie były niekompatybilne ze sobą nawzajem.

Widząc rozwój nie tylko jednej, ale wielu różnych alternatyw dla szacownego LPD, Grant Taylor, autor Linux Printing HOWTO, w swojej „Kampanii Zakazująca LPD”, wykrzyknął LPD Musi Umrzeć!.

Równolegle z powyższym, po stronie przemysłowej, dokonywano wysiłków, by przezwyciężyć dobrze znane słabości LPD. Zaczęto od firmowych rozszerzeń do starego LPD, i ciągnięto to do czasu, kiedy Hewlett-Packard® spróbował ustanowić HP® JetDirect jako nowy standard dla protokołu drukowania sieciowego. Rezultatem było tylko jeszcze więcej niezgodności.

Mniej więcej wtedy zaczął kształtować się pomysł określenia nowego, wspólnego standardu. Tak powstał IETF - Internet Engineering Task Force. Jednocześnie zorganizowała się grupa nazwana „Printer Working Group”, czyli PWG, skupiająca dystrybutorów sprzętu, oprogramowania i systemów operacyjnych. Stworzyli oni nowy „Internet Printing Protocol”, czyli IPP. IPP v1.1 został zaakceptowany IETF, jako standard i jest teraz szeroko wspierany w Europie, Stanach Zjednoczonych i Japonii. Większość modeli drukarek sieciowych, prócz tradycyjnych LPR/LPD, czy JetDirect Printing, ma obecnie wbudowaną obsługę IPP.

IPP obiecywało rozwiązanie wielu problemów, z którymi musieli się borykać administratorzy sieci. Zwykle obsługują oni wiele różnorodnych środowisk sieciowych i spędzają większość czasu na rozwiązywaniu problemów związanych z drukowaniem.

Stworzenie zunifikowanego modelu funkcji zapytania dla drukarek i serwerów obsługujących IPP, umożliwiło przesyłanie plików i ustawień atrybutów zadań drukowania itp. IPP jest przeznaczone do działania z wszystkimi platformami systemów operacyjnych. Jego wprowadzenie zajmie zapewne jeszcze dużo czasu, ponieważ wiele starszych drukarek będzie działało jeszcze przez wiele lat. Dlatego w IPP poczyniono kroki w kierunku wstecznej kompatybilności wszystkich implementacji IPP. CUPS zapewnia możliwość działania IPP we wszystkich środowiskach.

Jego największą przewagą będzie integracja z istniejącymi szeroko wykorzystywanymi protokołami IP. Jako rozszerzenie rozpowszechnionego protokołu HTTP 1.1, dla celów przetwarzania plików wydruku i innych powiązanych danych, jest również łatwe do wprowadzenia w innych standardach aktualnie tworzonych i rozpowszechnianych:

Czy kiedykolwiek widziałeś pokaz możliwości CUPS w sieci? Musiałeś być pod wielkim wrażeniem, jeśli wcześniej nie wiedziałeś, czego się spodziewać.

Wyobraź sobie siebie jako administratora „LAN”. W celu przetestowania, zainstalowałeś w komputerze sieciowym pełną wersję KDE/CUPS, wraz z dwunastoma skonfigurowanymi drukarkami: PostScript®owymi, laserowymi, atramentowymi itd. Użytkownicy KDE na tym komputerze są bardzo szczęśliwi - mogą drukować jak nigdy wcześniej, „dzwoniąc we wszystkie dzwony i gwizdki” każdej drukarki. Sprawienie, by wszystko doskonale działało, zajęło Ci 2 godziny... a teraz pozostałych 100 użytkowników sieci chce tego samego. Ponownie dwie godziny na każdy komputer? Nie ma mowy, aby udało Ci się to skończyć przed upływem roku, nie sądzisz?

Nieprawda. Zmień tylko jedno ustawienie w oryginalnym komputerze z systemem CUPS, aby stał się on „serwerem”. Zainstaluj CUPS na pięciu innych komputerach, jako „klientach”. Zanim wrócisz do pierwszego klienta, użytkownicy będą już bawić się ustawieniami dla dwunastu drukarek, które określiłeś wcześniej na „serwerze”. W jakiś magiczny sposób drukarki te pojawiły się we wszystkich oknach „drukowania” pięciu nowych komputerów-klientów z zainstalowanym systemem CUPS.

Użytkownicy drukują, chociaż nie zainstalowano nawet jednego sterownika, ani nie określono kolejki drukowania.

Jak działa ta magia?

Odpowiedź nie jest wcale skomplikowana.

Jeśli serwer CUPS jest w sieci LAN, przekazuje nazwy wszystkich dostępnych drukarek do LAN, korzystając z protokołu UDP i portu 631. Port 631 jest zarezerwowany jako „powszechnie znany port” przez IANA („Internet Assigning Numbers Authority”) dla celów IPP. Wszyscy klienci CUPS odbierają informacje z serwera CUPS, przesyłane do ich portu 631. To stąd wiedzą o dostępnych drukarkach i w ten sposób dowiadują się o „ścieżkach” do drukarek.

Dzięki wykorzystaniu IPP, który jest całkiem mądrym rozszerzeniem HTTP v1.1, CUPS jest w stanie podać adres wszystkich obiektów związanych z systemem drukowania poprzez „Universal Resource Locators” lub inaczej - URL. Dzięki IPP i CUPS, poprzez konkretny URL, można podać adres wszystkich działań takich jak usuwanie lub restartowanie zadań drukowania, odpytywanie i modyfikowanie drukarek, czy zadania administracyjne przeprowadzane na serwerze. Poprzez interfejs sieciowy systemu CUPS, dostępny na przykład przez Konquerora, można przeprowadzić wiele różnych operacji.

Klienci mogą „administrować” i „używać” każdą drukarką, jaką widzą tak, jakby to było urządzenie zainstalowane lokalnie. Można oczywiście ustawić pewne ograniczenia na listach kontroli dostępu, tak, aby nie każdy klient mógł używać każdej drukarki wedle własnego życzenia.

Klienci mogą nawet drukować bez odpowiedniego filtra (lub sterownika) zainstalowanego lokalnie.

Jak to działa? Jeśli klient chce dowiedzieć się czegoś o specyficznych opcjach wybranej drukarki, wysyła zapytanie (nazywane CUPS-get-ppd) do serwera. Serwer przekazuje klientowi wszystkie dane na temat określonych opcji, jakie odczytał z PPD. Użytkownik po stronie klienta może zobaczyć opcje i wybrać te pożądane. Następnie wysyła, korzystając z IPP jako protokołu transportu, plik do drukowania, zwykle nieprzefiltrowany PostScript® w trybie „raw”, z określonymi opcjami drukowania, do serwera drukowania. Wszystkie późniejsze działania, zwłaszcza filtrowanie, określanie końcowego formatu dla drukarki docelowej, są dokonywane przez serwer. Serwer posiada i obsługuje konieczne programy („sterowniki” lub „filtry”) do przeprowadzania podobnych operacji.

W ten sposób klient drukuje bez konieczności lokalnego instalowania sterowników.

Każda zmiana na serwerze, jak na przykład dodanie lub zmodyfikowanie drukarki, jest natychmiast „znana” klientowi bez potrzeby jakiejkolwiek konfiguracji.

Jedną z zaawansowanych cech systemu CUPS jest umiejętność „równoważenia obciążenia”.

Jeśli określisz takie same kolejki drukowania na dwóch różnych (lub więcej) serwerach, klienci wyślą swoje zadania do pierwszego odpowiadającego i dostępnego serwera. Jest to możliwe dzięki automatycznemu równoważeniu obciążenia między serwerami. Jeśli musisz wyłączyć z sieci jeden serwer w celach administracyjnych, inne przejmą jego zadania w taki sposób, że użytkownik nawet nie poczuje różnicy.