IPP> OPS - Ok that the 'any-value' out-of-band value has an attribute value?

IPP> OPS - Ok that the 'any-value' out-of-band value has an attribute value?

Hugo Parra HPARRA at novell.com
Thu Mar 9 14:41:30 EST 2000


See my comments below.
-Hugo

>>> "Hastings, Tom N" <hastings at 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 at hitachi-hkis.com] 
> Sent: Thursday, March 09, 2000 10:08
> To: Hugo Parra
> Cc: hastings at cp10.es.xerox.com; ipp at 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 &mdash; the value has no
> meaning when the value-tag has an "out-of-band" value." -Hugo
>




More information about the Ipp mailing list