RFC2910 & RFC8010 in 3.1.3 doesn't say something against attributes dublicates

[nikitasius]

Hi,
here is packet from debian11 cups, printing testing page just after adding the printer:

Here you say "RFC2910: Within an attribute group, if two or more attributes have the same name, the attribute group is malformed (see [RFC2911] section 3.1.3). Throw if someone attempts this."

• jipp/jipp-core/src/main/java/com/hp/jipp/encoding/AttributeGroupImpl.kt

  Line 19 in 7e2a5c0

  // is malformed (see [RFC2911] section 3.1.3). Throw if someone attempts this.

While RFC2910 nor RFC8010 doesn't say that. It just mention how it should be formatted but doesn't say that having attribute dublicates aren't allowed.

So in actual case it's better to parse and add again a attribute dublicate into your hashset to overwrite existing value instead of throw an exception and interrupt the packet building flow (ippStream.readPacket()).

[wifiprintguy]

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.

[nikitasius]

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

[gmuth]

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.

[nikitasius]

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.

[gmuth]

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

[nikitasius]

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.

[gmuth]

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

[nikitasius]

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).

[HPNavjot]

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.

[HPSudip]

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