IPP Mail Archive: RE: IPP> OPS - Ok that the 'any-value' out

IPP Mail Archive: RE: IPP> OPS - Ok that the 'any-value' out

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

From: Hugo Parra (HPARRA@novell.com)
Date: Thu Mar 09 2000 - 14:41:30 EST

  • Next message: McDonald, Ira: "RE: IPP> Revised I-D for SLP 'printer:' template"

    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 &mdash; 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