attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META content='"MSHTML 4.72.3110.7"' name=GENERATOR> </HEAD> <BODY bgColor=#ffffff style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px"> <DIV>Tom,</DIV> <DIV> </DIV> <DIV>"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.</DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>-Hugo</DIV> <DIV> </DIV> <DIV> >>> "Hastings, Tom N" <<A href="mailto:hastings@cp10.es.xerox.com">hastings@cp10.es.xerox.com</A>> 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 > </DIV></BODY></HTML>