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? [URGENT email discussion needed]

From: Hugo Parra (HPARRA@novell.com)
Date: Wed Mar 15 2000 - 12:29:42 EST

  • Next message: Hugo Parra: "Re: IPP> OPS - Ok that the 'any-value' out-of-band value has an attribute value? [URGENT email discussion needed]"

    Tom,

    "An IPP object MUST be able to accept any of the attribute syntaxes defined in Section 4.1, including their full range" (MOD Section 5.2.6). The "full range" for an out-of-band value is clearly "defined in Section 4.1" as ... "clients MUST NOT supply attributes with "out-of-band" values." There is no discrepancy between Sections 4.1 and 5.2.6 as currently stated. In my opinion, the "clarification" you propose goes against the initial intent of what's currently stated in the document and should be viewed as an interoperability breach with IPP 1.0/1.1.

    If the MOD spec is going to "mandate" that all compliant printer implementations MUST be able to accept "out-of-band" values with zero, one, or more values, the version number of IPP should be rev'ed up.

    -Hugo

    >>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 03/14/00 12:56PM >>>
    URGENT INTEROPERABILITY PROBLEM/ISSUE RELATED TO FUTURE EXTENSIONS
    for this week's IPP telecon, Wednesday, 3/15, 10-12 PST (1-3 EST). Please
    send comments by email as well, as usual.

    Hugo,

    Good catch from the Model and Semantics document. You wrote the following
    three paragraphs:

    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.

    That section in the IPP Model and Semantics document goes on to say:

    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. All attributes in a response MUST have one or more
    values as defined in Sections 4.2 to 4.4 or a single "out-of-band" value.

    So for IPP/1.1, the intent was that the out-of-band values are only for
    responses, and not for requests. And an "out-of-band" value can occur alone
    in a response, it cannot occur in combination with other values.

    However, some of the extensions that we have in the works need/allow for new
    out-of-band values not defined in IPP/1.1 to be sent in a request:

    a. for creating jobs with "xxx" collection attributes for which the Printer
    might have an "xxx-default" configured, that the client doesn't want, the
    client can supply the new 'none' out-of-band value. This 'none' value also
    seem useful for several other attribute syntaxes that don't have a natural
    "none" defined, such as mimeMediaType and uriScheme.

    b. For the Set-Job-Attributes and Set-Printer-Attributes operations, we have
    the need for the client to submit the 'delete-attribute' out-of-band value.

    c. For the Set-Printer-Attributes operation we allow the System
    Administrator to send the IPP/1.1 'no-value' out-of-band value in a request
    in order to set a Printer attribute back to the unconfigured value.

    d. In the Get-Printer-Supported-Values, we allow the new 'any-value' (in
    combination with the 'name' attribute syntax value) to come back in a
    response with other values.

    So we want to continue these extensions, we will need to clarify the Model
    document to indicate that the restriction on sending out-of-band values
    applies to the out-of-band values defined in this document and that future
    out-of-band values may be defined for use in requests.

    ISSUE: Ok to clarify the Model and Semantics document by clarifying the
    following paragraph:

    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. All attributes in a response MUST have one or more
    values as defined in Sections 4.2 to 4.4 or a single "out-of-band" value.

    to:

    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 any of
    the "out-of-band" values defined in this document. However, future
    extensions may allow specific out-of-band values in requests. All
    attributes in a response MUST have one or more values as defined in Sections
    4.2 to 4.4 or a single "out-of-band" value defined in this document. In the
    future, certain "out-of-band" values MAY be allowed in combination with
    other values in a response.

    This would be the same kind of a clarification for the Model and Semantics
    document that we have just done for the Transport and Encoding document (see
    thread below). In the Transport and Encoding document we have clarified
    that the zero-length requirement for out-of-band values applies to the three
    values defined in this document. Then a future out-of-band definition could
    have a non-zero length, if we agree to allow a new out-of-band value
    definition to allow/require a value (non-zero length).

    Comments?

    BTW, the Conformance section for IPP/1.1 has the following requirement which
    was put there in order to allow us to define extensions in requests that
    would not confuse or break Printers:

    5.2.6 Attribute Syntaxes
    An IPP object MUST be able to accept any of the attribute syntaxes defined
    in Section 4.1, including their full range, in any operation in which a
    client may supply attributes or the system administrator may configure
    attributes (by means outside the scope of this IPP/1.1 document). In
    particular for each attribute that the IPP object supports whose attribute
    syntax is 'text', the IPP object MUST accept and process both the
    'textWithoutLanguage' and 'textWithLanguage' forms. Similarly, for each
    attribute that the IPP object supports whose attribute syntax is 'name', the
    IPP object MUST accept and process both the 'nameWithoutLanguage' and
    'nameWithLanguage' forms. Furthermore, an IPP object MUST return attributes
    to the client in operation responses that conform to the syntax specified in
    Section 4.1, including their full range if supplied previously by a client.

    Tom

    -----Original Message-----
    From: Hugo Parra [mailto:HPARRA@novell.com]
    Sent: Thursday, March 09, 2000 11:42
    To: hastings@cp10.es.xerox.com; rbergma@hitachi-hkis.com
    Cc: ipp@pwg.org
    Subject: RE: IPP> OPS - Ok that the 'any-value' out-of-band value has an
    attribute value?

    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 : Wed Mar 15 2000 - 12:36:08 EST