Comment 13 for bug 856776

# User-Agent: CUPS/1.6.2 (Linux 3.8.0-29-generic; x86_64) IPP/2.0

We have a 'secure' (= cannot print without logging in with a fob) printing system working on a Ricoh printer. The cups server is running on my workstation, and I'm working mostly off of packet capture.

I *CAN* send a secured job to the printer *if* I do it from the command line and invoke the -U flag (lp -p <printer> -U <username> <filename>); I can see in the request packet the 'requesting-user-name' is set properly (my 'organizational' user name, not my username on the local system).

I have tried the following:
* putting 'Option job-originating-user-name <username>' in the /etc/cups/printers.conf file (per Migas)
* adding 'job-originating-user-name' 'requesting-user-name' 'user-name' with my institutional user name in the printer dialog box ('job options') ... and combinations thereof. I can also confirm that these get indeed added to the printers.conf file.
* adding 'job-originating-user-name=<username>' and 'requesting-user-name <username>' to the local printer options in ~/.cups/lpoptions ('Dest <printer> job-originating-user-name=<username> requesting-user-name <username>') and I have also set each one in turn in that file.

In *none* of these cases does the cups server appear to pick up on any of the settings, because I only ever find my username on the local system in print requests (as obtained via packet captures).

Clearly, the plumbing to be able to *send* a print job as another 'user' exists in cups (as evidenced by the ability to set it manually on a cli-based print request). The information supplied to the printer config dialog is clearly going into the printers.conf file. Other print options are being read by the server, so in theory these other options should be read as well (how to confirm?). Either the option is not being read (ignored because it's not an option the server thinks it can handle?) or it isn't being passed on even though the server will otherwise send the local user name.