RFC2910 & RFC8010 in 3.1.3 doesn't say something against attributes dublicates about jipp HOT 10 CLOSED

RFC 2911 says that, not 2910. The problem is the citation. RFC 8011 (replaced RFC 2911) section 4.1.3 is where the citation lives:

The attributes within a group MUST be unique; if an attribute with
the same name occurs more than once, the group is malformed. Clients
MUST NOT submit such malformed requests, and Printers MUST NOT return
such malformed responses. If such a malformed request is submitted
to a Printer, the Printer MUST either (1) reject the request with the
’client-error-bad-request’ status-code (RECOMMENDED -- see
Appendix B.1.4.1) or (2) process the request normally after selecting
only one of the attribute instances, depending on implementation.
Which attribute is selected when there are duplicate attributes
depends on implementation. The IPP Printer MUST NOT use the values
from more than one such duplicate attribute instance.

from jipp.

Even the IPP reference implementation CUPS sometimes responds with duplicate attributes. So resilience for this issue is highly recommended. Adding the attribute again sounds okay to me.

from jipp.

Yep, but

The attributes within a group MUST be unique; if an attribute with
the same name occurs more than once, the group is malformed. Clients
MUST NOT submit such malformed requests, and Printers MUST NOT return
such malformed responses. If such a malformed request is submitted
to a Printer, the Printer MUST either (1) reject the request with the
'client-error-bad-request' status-code (RECOMMENDED -- see
Appendix B.1.4.1) or (2) process the request normally after selecting
only one of the attribute instances, depending on implementation.
Which attribute is selected when there are duplicate attributes
depends on implementation. The IPP Printer MUST NOT use the values
from more than one such duplicate attribute instance.

Thats what i need:

(2) process the request normally after selecting
only one of the attribute instances, depending on implementation.
Which attribute is selected when there are duplicate attributes
depends on implementation

from jipp.

Agree.

Even the IPP reference implementation CUPS sometimes responds with duplicate attributes. So resilience for this issue is highly recommended. Adding the attribute again sounds okay to me.

Agree, i had to edit that lib and rebuild it to be able to use w/ cups correctly.

from jipp.

Alternatively you could use this CupsClient which supports already some additional CUPS operations (e.g. job subscriptions and printer setup)

from jipp.

No, this lib is fine. I made for me an IPP server using vert.x and this lib.
So the issue i described here i faced during debug.

from jipp.

So, how about contributing to the IPP community your IPP server?

from jipp.

So, how about contributing to the IPP community your IPP server?

i need to make it nice and remove shitcode from :)

thats for debug purposes. Works for win (spooler) & linux (cups), but i need to read more docs to make it nice and customisable.

The advantage to use vertx it's cause it's small, fast, reactive & IPP use simple http/https. So vertx is a core and it have simple flow (which use kind of my "lib" which use that lib).
Project is on Java (i don't code on kotlin).

from jipp.

Analyzed RFC8011 section 4.1.3
The attributes within a group MUST be unique; if an attribute with the same name occurs more than once, the group is malformed. Clients MUST NOT submit such malformed requests, and Printers MUST NOT return such malformed responses. If such a malformed request is submitted to a Printer, the Printer MUST either (1) reject the request with the 'client-error-bad-request' status-code (RECOMMENDED -- see [Appendix B.1.4.1](https://www.rfc-editor.org/rfc/rfc8011.html#appendix-B.1.4.1)) or (2) process the request normally after selecting only one of the attribute instances, depending on implementation. Which attribute is selected when there are duplicate attributes depends on implementation. The IPP Printer MUST NOT use the values from more than one such duplicate attribute #instance.

with above comments in consideration, we are reconsidering the logic.

from jipp.

This is taken care and available in the latest release. Hence closing.

from jipp.