See my comments below.
-Hugo
>>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 03/09/00 12:02PM >>>
> Here is what IPP/1.0 and IPP/1.1 [ipp-pro] documents up until the March 1,
> 2000 version have said:
>
> If a value-tag contains an "out-of-band" value, such as "unsupported", the
> value-length MUST be 0 and the value empty - the value has no meaning when
> the value-tag has an "out-of-band" value.
>
>
> Here is the new paragraph in the March 1, 2000 [ipp-pro] version:
>
> If a value-tag contains an "out-of-band" value defined in this document,
> such as "unsupported", the value-length MUST be 0 and the value empty; the
> value has no meaning when the value-tag has one of these "out-of-band"
> values. However, the definitions of additional "out-of-band" values in
> future documents are able to explicitly use the value field and have a
> value-length that is non-zero, if there is a need for additional information
> to be associated with the out-of-band value. Unless the definition of an
> "out-of-band" value explicitly allows for a value, the value-length MUST be
> 0 and the value empty.
>
>
> The intent of this March 1, 2000 clarification was to limit the restriction
> to existing defined out-of-band values in [ipp-pro], namely, 'unsupported',
> 'no-value', and 'unknown', and to allow future definitions of NEW
> out-of-band values to have a value if the definition needed such a value.
> So the three out-of-band values defined so far in [ipp-pro] are defined to
> REQUIRE 0 length, but the clarification allows us in the future, if we want
> (and if it doesn't break existing clients accepting responses, or existing
> servers accepting requests) to define NEW out-of-band values which do use
> the length field (such as the 'any-value'). However, if this is going to
> break existing clients and existing servers, then we shouldn't define new
> out-of-band values with non-zero length. However, lets be clear,
> implementers aren't free to add values to out-of-band values, unless the
> definition of that out-of-band value allows a non-zero value field.
>
> We have the following new out-of-band values in IPP extension documents:
>
> 'none', 'not-settable', 'delete-attribute', and 'any-value'
>
> and [ipp-pro] reserves the 'default' out-of-band value for future
> definition. O Of all these values, only the 'any-value' is proposed to have
> a non-zero value field (which contains the attribute syntax code that the
> 'any-value' goes with). None of the other proposed out-of-band values have
> a non-zero length.
>
> If having a non-zero length for 'any-value' is a real compatibility problem
> (see questions to Hugo below), then a possibility would be to define
> 'any-value' with a zero-length and say that the definition of the attribute
> indicates what attribute syntax the 'any-value' goes with. This could be
> done by changing the "Job and Printer Set Operations" document only. The
> [ipp-pro] could still leave us the possibility in the future as in the March
> 1, 2000 text.
>
> Comments?
>
>
> Hugo,
>
> What does your server code do if it gets an out-of-band value with a
> non-zero length?
Novell's shipping implementation of the IPP Server does not accept *any* "out-of-band" values as per section 4.1 of the "IPP/1.1: Model and Semantics" document:
"All attributes in a request MUST have one or more values as defined in Sections 4.2 to 4.4. Thus clients MUST NOT supply attributes with "out-of-band" values."
We currently discard a request in its entirety if it contains an "out-of-band" value.
>
> a. Reject the request with client-error-bad-request or some such code?
> b. Change the length to 0 and throw away the value data?
> c. return the attribute in the Unsupported Attributes Group?
>
> What does your client code do if it gets an out-of-band value with a
> non-zero length?
>
> a. simply skip over the value field as with any other value
> b. ignore the length, assume that it meant to be 0, and try to interpret
> the value field as the next length field (and get terribly confused)?
> c. bother the user with a message about the server returning incorrect
> syntax?
Novell's IPP Gateway allows an NDPS Printer Agent to front-end an IPP printer device. It doesn't have a UI of its own but causes NDPS printer and job state and state reasons to be set to reflect its interaction with the device. Currently, if it runs into a non-zero length "out-of-band" value it discards the IPP response in its entirety. The ramifications of this failure depend on the specific IPP operation that failed.
As I stated in a previous message, this is not shipping code and can be easily modified. The IPP Server code is a different story, though.
>
>
> NOTE: that the 'any-value' out-of-band value with a non-zero length field is
> only defined so far for the new Get-Printer-Supported-Values operation.
> Does limiting it to this purpose help with the backwards compatibility
> problem?
>
> However, it could be used in any "xxx-supported" attributes to indicate that
> validation is not performed on that attribute (something Carl Kugler
> mentioned a need for certain servers that just want to store away or forward
> jobs without validating them). When used for this purpose, it might then be
> used in a Set-Printer-Attributes operation to configure an "xxx-supported",
> so it could go in the client to server direction. But again the
> Set-Printer-Attributes is a new operation. The only problem with existing
> client or server code would be a client that did a Get-Printer-Attributes
> requesting "xxx-supported" where it might get back the 'any-value'
> out-of-band value. But what would such a client (like yours) do?
> Hopefully, not crash. If the client quietly skips over the value field as
> with any other attribute value, then there shouldn't be any problem, even
> with this use of 'any-value'.
>
> But in any case, we need to be very careful not to define things that will
> break existing implementations, hence this mail thread.
>
> Comments?
>
> Thanks,
> Tom
>
>
>
> -----Original Message-----
> From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
> Sent: Thursday, March 09, 2000 10:08
> To: Hugo Parra
> Cc: hastings@cp10.es.xerox.com; ipp@pwg.org
> Subject: Re: IPP> OPS - Ok that the 'any-value' out-of-band value hasan
> attribute value?
>
>
> All,
>
> In the IPP 1.1 Protocol document, the paragraph cited
> by Hugo goes on to read...
>
> "However, the definitions of additional "out-of-band"
> values in future documents are able to explicitly use the value field
> and have a value-length that is non-zero, if there is a need for
> additional information to be associated with the out-of-band value.
> Unless the definition of an "out-of-band" value explicitly allows for a
> value, the value-length MUST be 0 and the value empty."
>
> So a 1.1 implemetation must not break, but a 1.0 might.
>
> Ron Bergman
> Hitachi Koki Imaging Solutions
>
>
> Hugo Parra wrote:
>
> All, Our current client implementation (Novell's IPP Gateway) checks
> that all "out of band" attributes have value lengths of zero. This
> code hasn't yet been officially released, so it's still possible to
> change it, if needs be. But make no mistake, allowing non-zero values
> for "out-of-band" values does break the current IPP rules. Section
> 3.10 of the "IPP/1.0: Encoding and Transport" document reads: "If a
> value-tag contains an "out-of-band" value, such as "unsupported", the
> value-length MUST be 0 and the value empty — the value has no
> meaning when the value-tag has an "out-of-band" value." -Hugo
>
This archive was generated by hypermail 2b29 : Thu Mar 09 2000 - 14:48:07 EST