attributes-natural-language "en-US" is rejected by PAPPL >= 1.4.12 printers (RFC 8011 requires lowercase)
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 84/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- go
- Domain
- networking
Research direction
The request is built in ippGetPrinterAttributes() in ipp.go, around lines 118-119, where attributes-natural-language is set to "en-US". Read the RFC 8011 lowercase requirement the issue cites, then check how the other IPP requests in that file set language values. Done means the attribute is sent in lowercase and a PAPPL 1.4.12 printer returns successful-ok, which the reporter confirmed with ipptool print-job.test.
Written by the indexing model from the issue text.
Description
Summary
ippGetPrinterAttributes() in ipp.go sends attributes-natural-language = "en-US". RFC 8011 §5.1.9 requires lowercase natural-language values in IPP ("IPP requires all lowercase values in IPP attributes", example 'en-us'). Since PAPPL 1.4.12, PAPPL-based printers validate this and reject the request with client-error-bad-request. ipp-usb then treats the device as having no IPP service and fails init with "Device doesn't implement print or scan service". No bridge port is ever opened.
This affects every printer whose firmware is built on PAPPL ≥ 1.4.12. We hit it on a Rollo X1040 label printer after the printer updated its own firmware.
Code
msg.Operation.Add(goipp.MakeAttribute("attributes-natural-language",
goipp.TagLanguage, goipp.String("en-US")))
Printer side
PAPPL commit 77d77816 ("Update poll error handling for consistency") added request-level validation:
else if (language && !ippValidateAttribute(language))
papplClientRespondIPP(client, IPP_STATUS_ERROR_BAD_REQUEST,
"Bad \"attributes-natural-language\" value '%s'.", ...);
The check is in _papplClientProcessIPP(), so it applies to every operation. ippValidateAttribute() in CUPS 2.4.x validates naturalLanguage values against a lowercase-only pattern.
Observed
Printer: Rollo X1040 (USB 09c5:1040).
Host: Debian 13 (Trixie) arm64, ipp-usb 0.9.23-1+b4. Current master has the same code.
The printer updated its own firmware between these two sessions. Same printer, same host, same ipp-usb, same en-US request.
Firmware 1.6.40 / PAPPL 1.4.8 accepts it (/var/log/ipp-usb/09c5-1040-<serial>-Rollo-X1040-Label-Printer.log):
16-09-2026 10:15:52: > ATTR "attributes-natural-language" naturalLanguage: en-US
16-09-2026 10:15:52: < Server: Rollo_AirPrint/1.6.40 PAPPL/1.4.8 CUPS IPP/2.0
16-09-2026 10:15:52: < STATUS successful-ok
Firmware 1.6.66 / PAPPL 1.4.12 rejects it:
07-10-2026 13:02:49: > ATTR "attributes-natural-language" naturalLanguage: en-US
07-10-2026 13:02:50: < Server: Rollo_AirPrint/1.6.66 PAPPL/1.4.12 CUPS IPP/2.0
07-10-2026 13:02:50: < STATUS client-error-bad-request
07-10-2026 13:02:50: < ATTR "status-message" textWithoutLanguage: Bad "attributes-natural-language" value 'en-US'.
07-10-2026 13:02:50: ! IPP: IPP: client-error-bad-request
07-10-2026 13:02:50: ! ESCL: eSCL: HTTP status: 404 Not Found
07-10-2026 13:02:50: - Bus 001 Device 004: resetting X1040 Label Printer
and main.log:
07-10-2026 13:02:50: ! PNP Bus 001 Device 004: Device doesn't implement print or scan service
Tested fix
I built 0.9.23 with only "en-US" changed to "en-us" and ran it against the same printer on firmware 1.6.66:
09-10-2026 10:21:01: > ATTR "attributes-natural-language" naturalLanguage: en-us
09-10-2026 10:21:02: < Server: Rollo_AirPrint/1.6.66 PAPPL/1.4.12 CUPS IPP/2.0
09-10-2026 10:21:02: < STATUS successful-ok
Init completed, the device was published via DNS-SD, and a PDF sent with ipptool (print-job.test) through the bridge printed (job-state = completed, job-completed-successfully).
Proposed fix
Change "en-US" to "en-us" in ippGetPrinterAttributes. I'll open a PR with this change.
Assisted-by: Claude:claude-opus-5-5 Claude Code
- Dominant language
- Go
- Stars
- 210
- Forks
- 33
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenPrinting/ipp-usb
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
OpenPrinting/ipp-usb#136 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
OpenPrinting/ipp-usb#124 · 5 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 32/100
OpenPrinting/ipp-usb#123 · 10 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
OpenPrinting/ipp-usb#122 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
OpenPrinting/ipp-usb#116 · 2 comments ·
All issues in OpenPrinting/ipp-usb
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
siyuan-note/siyuan#20353 ·
Maintainers usually reply within 1 day
-
Discriminator mapping keys are listed in a random orderPossibly taken @reuvenharrison claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Idle compaction monitors LIST the replica every tick when the newest destination file spans more than one TXIDPossibly taken @pishuv claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
benbjohnson/litestream#1563 ·
Maintainers usually reply within 2 days
-
triage needed
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day