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 at novell.com]
Sent: Thursday, March 09, 2000 11:42
To: hastings at cp10.es.xerox.com; rbergma at hitachi-hkis.com
Cc: ipp at 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 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 — the value has no
> meaning when the value-tag has an "out-of-band" value." -Hugo
>