I see what you're talking about, but I don't think 16.3.3 should be in the
document (just my opinion). The request-id should be an unsigned opaque
value to the server. If I were you I would just return whatever value the
client gave you; IMHO, it's the safe bet.
Randy
-----Original Message-----
From: Hugo Parra [mailto:HPARRA@novell.com]
Sent: Friday, August 28, 1998 2:40 PM
To: rturner@sharplabs.com
Subject: Re: RE: IPP> Handling of invalid "request-id"
Randy,
I'm reading section 16.3.3 of the "Model and Semantics" document.
-Hugo Parra
>>> "Turner, Randy" <rturner@sharplabs.com> 08/28 3:29 PM >>>
I can't remember if the request-id is the same as a request
"transaction-id", but if it is, the server never validates this field. It is
set by the client and echoed back by the server in the corresponding
response. There is no validity check made by the server (that I am aware
of).
Randy
-----Original Message-----
From: Hugo Parra [mailto:HPARRA@novell.com]
Sent: Friday, August 28, 1998 2:04 PM
To: ipp@pwg.org
Subject: IPP> Handling of invalid "request-id"
Suppose the Printer object, while parsing an IPP requests, fails to validate
the "request-id" in the incoming payload (because the packet was incomplete
or because the value is not between 1 and 2**31-1). The documents indicates
that the Printer object should return a 'client-error-bad-request' status
code. That's fine; now my question: What request-id should the Printer
object include in the response (I'm assuming that responses with error
status codes must also include version, request-id, charset, etc.)? Should
0 be used to handle this cases?
-Hugo Parra