[Info-vax] Encrypted TCP/IP network printserver spooled printing for OpenVMS (secure-IPP?)

[Mark Berryman]

On 5/3/18 10:40 AM, seasoned_geek wrote:
> On Sunday, April 29, 2018 at 4:46:05 PM UTC-5, Mark Berryman wrote:
>> On 4/27/18 5:11 PM, seasoned_geek wrote:
>>> On Friday, April 27, 2018 at 9:31:04 AM UTC-5, Dennis Boone wrote:
>>>>> CUPS is a nightmare and YOU LOSE ALL SUPPORT FOR POSTSCRIPT
>>>>    > OUTPUT. Everything sent to the drivers ___must___ be PDF.
>>>>
>>>> No kidding.  Well, ok, CUPS will cheerfully convert postscript to PDF,
>>>> and then back to postscript to send to the printer.  Or at least it
>>>> will try.  That usually fails, stranding jobs in the queue.  And the
>>>> code it generates mostly doesn't work on the printers.  CUPS is an
>>>> unmitigated disaster.
>>>>
>>>> De
>>>
>>> As of YABU 2014, or was it 2012, Apple mandated all drivers/ppd accept only PDF input. This is what broke everything. I could not get any postscript files to make it through CUPS no matter what I tried. If I managed to raw write them to the printer they printed just fine. (Printers had more than enough RAM to hold everything.)
>>>
>>> There are hundreds, if not thousands of PRODUCTION jobs creating Postscript output for paper invoices, account statements, etc. Most companies got rid of pre-printed forms if there was no legal requirement for pre-printed multi-part forms once they got comfortable with laser printers. If someone "ports" CUPS as the non-solution, they either don't actually port it or they break every one of those jobs.
>>>
>>> NONE of this transport level security should _ever_ be handled by an application. From what little I've read recently, both Unisys and IBM with z13/14 have implemented some kind of TCP/IP software appliance. Providing a single place to define and verify all of this stuff instead of having thousands of developers roll there own for each and every application.
>>>
>>
>> Um, Hogwash.
>> And even more hogwash.
>>
>> CUPS allows printing of just about any file type you'd ever want to send
>> to a printer.  It is also extensible enough that you can add new file
>> types if you've got something unique you need to print.
>>
>> Can't print a postscript file through CUPS, you say?  Hmmm...
>>
>> (Searching for any old postscript file I might still have lying around...)
>>
>> $ lp WotCharSheet.ps
>> request id is Lexmark_CX410de-31 (1 file(s))
>> $
> 
> 
>> As for your claim that CUPS removed support for locally attached
>> printers (serial, parallel, USB) - nope, didn't happen.  CUPS is the
>> printing subsystem in MacOS and MacOS most definitely still supports
>> locally attached printers.  Want further proof?  Download the source
>> code.  The necessary support is still there.
>>
>> I will also point out that encryption is built into IPP and is fully
>> supported by CUPS.
>>
> 
> Um, no. I got into this very argument when this very thing happened with whoever it was in Apple in charge of the CUPS project when they did it. The serial and parallel support was removed and the required input file was changed to PDF. What was Apple's justification?
> 
> We no longer make any computers with those types of ports.

I'll try once more.  Hard evidence.

 From the CUPS source code:

 From the file ieee1284.c (IEEE 1284 is the parallel port standard):

Looking at the first subroutine in the file:

/*
  * 'backendGetDeviceID()' - Get the IEEE-1284 device ID string and
  *                          corresponding URI.
  */

int                                     /* O - 0 on success, -1 on 
failure */
backendGetDeviceID(
     int        fd,                      /* I - File descriptor */
     char       *device_id,              /* O - 1284 device ID */
     int        device_id_size,          /* I - Size of buffer */
     char       *make_model,             /* O - Make/model */
     int        make_model_size,         /* I - Size of buffer */
     const char *scheme,                 /* I - URI scheme */
     char       *uri,                    /* O - Device URI */
     int        uri_size)                /* I - Size of buffer */
{
#ifdef __APPLE__ /* This function is a no-op */
   (void)fd;
   (void)device_id;
   (void)device_id_size;
   (void)make_model;
   (void)make_model_size;
   (void)scheme;
   (void)uri;
   (void)uri_size;

   return (-1);

#else /* Get the device ID from the specified file descriptor... */

In other words, it is a null function for *Apple*, since Apple doesn't 
put parallel ports on their hosts anymore, but is fully functioning for 
anyone else.

Then there are the following files in the source tree:
usb-darwin.c
usb-libusb.c
usb-unix.c
usb.c

These provide support for printers connected via USB ports (that would 
be the serial connections that supposedly disappeared).  Works on Apple 
systems.  Works on Unix systems.  Likely requires porting to work on VMS 
systems.

And, finally, take a look at this Linux Foundation Wiki entry;
https://wiki.linuxfoundation.org/openprinting/pdf_as_standard_print_job_format

It talks about the switch to printing using a PDF workflow, the benefits 
thereof, the wide adoption thereof within the Linux world, and even how 
to configure CUPS so that printing a PS file to a PS printer is sent 
native without going through PS->PDF->PS.

You are free to believe as you will.  But the evidence contravenes your 
statements.

Mark Berryman