<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
<BODY bgColor=#ffffff 
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV>&quot;An IPP object MUST be able to accept any of the attribute syntaxes 
defined in Section 4.1, including their full range&quot; (MOD Section 
5.2.6).&nbsp; The &quot;full range&quot; for an out-of-band value is clearly 
&quot;defined in Section 4.1&quot; as ... &quot;clients MUST NOT supply 
attributes with &quot;out-of-band&quot; values.&quot;&nbsp; There is no 
discrepancy between Sections 4.1 and 5.2.6 as currently stated.&nbsp; In my 
opinion, the &quot;clarification&quot; 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>If the MOD spec is going to &quot;mandate&quot; that all compliant printer 
implementations MUST be able to accept &quot;out-of-band&quot; values with zero, 
one, or more values, the version number of IPP should be rev'ed up.</DIV>
<DIV><BR><BR>&gt;&gt;&gt; &quot;Hastings, Tom N&quot; &lt;<A 
TO FUTURE EXTENSIONS<BR>for this week's IPP telecon, Wednesday, 3/15, 10-12 PST 
(1-3 EST).&nbsp; Please<BR>send comments by email as well, as 
usual.<BR><BR>Hugo,<BR><BR>Good catch from the Model and Semantics document. You 
wrote the following<BR>three paragraphs:<BR><BR>Novell's shipping implementation 
of the IPP Server does not accept *any*<BR>&quot;out-of-band&quot; values as per 
section 4.1 of the &quot;IPP/1.1: Model and<BR>Semantics&quot; 
document:<BR><BR>&quot;All attributes in a request MUST have one or more values 
as defined in<BR>Sections 4.2 to 4.4.&nbsp; Thus clients MUST NOT supply 
attributes with<BR>&quot;out-of-band&quot; values.&quot;<BR><BR>We currently 
discard a request in its entirety if it contains an<BR>&quot;out-of-band&quot; 
value.<BR><BR><BR><BR>That section in the IPP Model and Semantics document goes 
on to say:<BR><BR>All attributes in a request MUST have one or more values as 
defined in<BR>Sections 4.2 to 4.4.&nbsp; Thus clients MUST NOT supply attributes 
with<BR>&quot;out-of-band&quot; values.&nbsp; All attributes in a response MUST 
have one or more<BR>values as defined in Sections 4.2 to 4.4 or a single 
&quot;out-of-band&quot; value.<BR><BR>So for IPP/1.1, the intent was that the 
out-of-band values are only for<BR>responses, and not for requests.&nbsp; And an 
&quot;out-of-band&quot; value can occur alone<BR>in a response, it cannot occur 
in combination with other values.<BR><BR><BR><BR>However, some of the extensions 
that we have in the works need/allow for new<BR>out-of-band values not defined 
in IPP/1.1 to be sent in a request:<BR><BR>a. for creating jobs with 
&quot;xxx&quot; collection attributes for which the Printer<BR>might have an 
&quot;xxx-default&quot; configured, that the client doesn't want, the<BR>client 
can supply the new 'none' out-of-band value.&nbsp; This 'none' value 
also<BR>seem useful for several other attribute syntaxes that don't have a 
natural<BR>&quot;none&quot; defined, such as mimeMediaType and 
uriScheme.<BR><BR>b. For the Set-Job-Attributes and Set-Printer-Attributes 
operations, we have<BR>the need for the client to submit the 'delete-attribute' 
out-of-band value.<BR><BR>c. For the Set-Printer-Attributes operation we allow 
the System<BR>Administrator to send the IPP/1.1 'no-value' out-of-band value in 
a request<BR>in order to set a Printer attribute back to the unconfigured 
value.<BR><BR>d. In the Get-Printer-Supported-Values, we allow the new 
'any-value' (in<BR>combination with the 'name' attribute syntax value) to come 
back in a<BR>response with other values.<BR><BR><BR>So we want to continue these 
extensions, we will need to clarify the Model<BR>document to indicate that the 
restriction on sending out-of-band values<BR>applies to the out-of-band values 
defined in this document and that future<BR>out-of-band values may be defined 
for use in requests.<BR><BR>ISSUE: Ok to clarify the Model and Semantics 
document by clarifying the<BR>following paragraph:<BR><BR>All attributes in a 
request MUST have one or more values as defined in<BR>Sections 4.2 to 4.4.&nbsp; 
Thus clients MUST NOT supply attributes with<BR>&quot;out-of-band&quot; 
values.&nbsp; All attributes in a response MUST have one or more<BR>values as 
defined in Sections 4.2 to 4.4 or a single &quot;out-of-band&quot; 
value.<BR><BR>to:<BR><BR>All attributes in a request MUST have one or more 
values as defined in<BR>Sections 4.2 to 4.4.&nbsp; Thus clients MUST NOT supply 
attributes with any of<BR>the &quot;out-of-band&quot; values defined in this 
document.&nbsp; However, future<BR>extensions may allow specific out-of-band 
values in requests.&nbsp; All<BR>attributes in a response MUST have one or more 
values as defined in Sections<BR>4.2 to 4.4 or a single &quot;out-of-band&quot; 
value defined in this document.&nbsp; In the<BR>future, certain 
&quot;out-of-band&quot; values MAY be allowed in combination with<BR>other 
values in a response.<BR><BR><BR><BR>This would be the same kind of a 
clarification for the Model and Semantics<BR>document that we have just done for 
the Transport and Encoding document (see<BR>thread below).&nbsp; In the 
Transport and Encoding document we have clarified<BR>that the zero-length 
requirement for out-of-band values applies to the three<BR>values defined in 
this document. Then a future out-of-band definition could<BR>have a non-zero 
length, if we agree to allow a new out-of-band value<BR>definition to 
allow/require a value (non-zero length).<BR><BR>Comments?<BR><BR><BR>BTW, the 
Conformance section for IPP/1.1 has the following requirement which<BR>was put 
there in order to allow us to define extensions in requests that<BR>would not 
confuse or break Printers:<BR><BR>5.2.6 Attribute Syntaxes<BR>An IPP object MUST 
be able to accept any of the attribute syntaxes defined<BR>in Section 4.1, 
including their full range, in any operation in which a<BR>client may supply 
attributes or the system administrator may configure<BR>attributes (by means 
outside the scope of this IPP/1.1 document).&nbsp; In<BR>particular for each 
attribute that the IPP object supports whose attribute<BR>syntax is 'text', the 
IPP object MUST accept and process both the<BR>'textWithoutLanguage' and 
'textWithLanguage' forms.&nbsp; Similarly, for each<BR>attribute that the IPP 
object supports whose attribute syntax is 'name', the<BR>IPP object MUST accept 
and process both the 'nameWithoutLanguage' and<BR>'nameWithLanguage' 
forms.&nbsp; Furthermore, an IPP object MUST return attributes<BR>to the client 
in operation responses that conform to the syntax specified in<BR>Section 4.1, 
including their full range if supplied previously by a 
client.<BR><BR>Tom<BR><BR><BR><BR>-----Original Message-----<BR>From: Hugo Parra 
[]<BR>Sent: Thursday, March 09, 2000 11:42<BR>To:;<BR>Cc:<BR>Subject: RE: IPP&gt; OPS - Ok that the 'any-value' out-of-band 
value has an<BR>attribute value?<BR><BR><BR>See my comments 
below.<BR>-Hugo<BR><BR>&gt;&gt;&gt; &quot;Hastings, Tom N&quot; 
&lt;; 03/09/00 12:02PM &gt;&gt;&gt;<BR>&gt; Here is 
what IPP/1.0 and IPP/1.1 [ipp-pro] documents up until the March 1,<BR>&gt; 2000 
version have said:<BR>&gt;<BR>&gt; If a value-tag contains an 
&quot;out-of-band&quot; value, such as &quot;unsupported&quot;, the<BR>&gt; 
value-length MUST be 0 and the value empty - the value has no meaning 
when<BR>&gt; the value-tag has an &quot;out-of-band&quot; value. 
<BR>&gt;<BR>&gt;<BR>&gt; Here is the new paragraph in the March 1, 2000 
[ipp-pro] version:<BR>&gt;<BR>&gt; If a value-tag contains an 
&quot;out-of-band&quot; value defined in this document,<BR>&gt; such as 
&quot;unsupported&quot;, the value-length MUST be 0 and the value empty; 
the<BR>&gt; value has no meaning when the value-tag has one of these 
&quot;out-of-band&quot;<BR>&gt; values.&nbsp; However, the definitions of 
additional &quot;out-of-band&quot; values in<BR>&gt; future documents are able 
to explicitly use the value field and have a<BR>&gt; value-length that is 
non-zero, if there is a need for additional<BR>information<BR>&gt; to be 
associated with the out-of-band value.&nbsp; Unless the definition of an<BR>&gt; 
&quot;out-of-band&quot; value explicitly allows for a value, the value-length 
MUST<BR>be<BR>&gt; 0 and the value empty.<BR>&gt;<BR>&gt;<BR>&gt; The intent of 
this March 1, 2000 clarification was to limit the<BR>restriction<BR>&gt; to 
existing defined out-of-band values in [ipp-pro], 
namely,<BR>'unsupported',<BR>&gt; 'no-value', and 'unknown', and to allow future 
definitions of NEW<BR>&gt; out-of-band values to have a value if the definition 
needed such a value.<BR>&gt; So the three out-of-band values defined so far in 
[ipp-pro] are defined to<BR>&gt; REQUIRE 0 length, but the clarification allows 
us in the future, if we<BR>want<BR>&gt; (and if it doesn't break existing 
clients accepting responses, or existing<BR>&gt; servers accepting requests) to 
define NEW out-of-band values which do use<BR>&gt; the length field (such as the 
'any-value').&nbsp; However, if this is going to<BR>&gt; break existing clients 
and existing servers, then we shouldn't define new<BR>&gt; out-of-band values 
with non-zero length.&nbsp;&nbsp; However, lets be clear,<BR>&gt; implementers 
aren't free to add values to out-of-band values, unless the<BR>&gt; definition 
of that out-of-band value allows a non-zero value field.<BR>&gt; <BR>&gt; We 
have the following new out-of-band values in IPP extension documents:<BR>&gt; 
<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 'none', 'not-settable', 'delete-attribute', and 
'any-value'<BR>&gt; <BR>&gt; and [ipp-pro] reserves the 'default' out-of-band 
value for future<BR>&gt; definition.&nbsp; O Of all these values, only the 
'any-value' is proposed to<BR>have<BR>&gt; a non-zero value field (which 
contains the attribute syntax code that the<BR>&gt; 'any-value' goes 
with).&nbsp; None of the other proposed out-of-band values<BR>have<BR>&gt; a 
non-zero length.<BR>&gt; <BR>&gt; If having a non-zero length for 'any-value' is 
a real compatibility<BR>problem<BR>&gt; (see questions to Hugo below), then a 
possibility would be to define<BR>&gt; 'any-value' with a zero-length and say 
that the definition of the<BR>attribute<BR>&gt; indicates what attribute syntax 
the 'any-value' goes with.&nbsp; This could be<BR>&gt; done by changing the 
&quot;Job and Printer Set Operations&quot; document only.&nbsp; The<BR>&gt; 
[ipp-pro] could still leave us the possibility in the future as in 
the<BR>March<BR>&gt; 1, 2000 text.<BR>&gt; <BR>&gt; Comments?<BR>&gt; <BR>&gt; 
<BR>&gt; Hugo,<BR>&gt; <BR>&gt; What does your server code do if it gets an 
out-of-band value with a<BR>&gt; non-zero length?&nbsp; <BR><BR>Novell's 
shipping implementation of the IPP Server does not accept 
*any*<BR>&quot;out-of-band&quot; values as per section 4.1 of the &quot;IPP/1.1: 
Model and<BR>Semantics&quot; document:<BR><BR>&quot;All attributes in a request 
MUST have one or more values as defined in<BR>Sections 4.2 to 4.4.&nbsp; Thus 
clients MUST NOT supply attributes with<BR>&quot;out-of-band&quot; 
values.&quot;<BR><BR>We currently discard a request in its entirety if it 
contains an<BR>&quot;out-of-band&quot; value.<BR><BR>&gt; <BR>&gt;&nbsp;&nbsp; 
a. Reject the request with client-error-bad-request or some such 
code?<BR>&gt;&nbsp;&nbsp; b. Change the length to 0 and throw away the value 
data?<BR>&gt;&nbsp;&nbsp; c. return the attribute in the Unsupported Attributes 
Group?<BR>&gt; <BR>&gt; What does your client code do if it gets an out-of-band 
value with a<BR>&gt; non-zero length?<BR>&gt; <BR>&gt;&nbsp;&nbsp; a. simply 
skip over the value field as with any other value<BR>&gt;&nbsp;&nbsp; b. ignore 
the length, assume that it meant to be 0, and try to interpret<BR>&gt; the value 
field as the next length field (and get terribly confused)?<BR>&gt;&nbsp;&nbsp; 
c. bother the user with a message about the server returning incorrect<BR>&gt; 
syntax?<BR><BR>Novell's IPP Gateway allows an NDPS Printer Agent to front-end an 
IPP<BR>printer device.&nbsp; It doesn't have a UI of its own but causes NDPS 
printer and<BR>job state and state reasons to be set to reflect its interaction 
with the<BR>device.&nbsp; Currently, if it runs into a non-zero length 
&quot;out-of-band&quot; value it<BR>discards the IPP response in its 
entirety.&nbsp; The ramifications of this<BR>failure depend on the specific IPP 
operation that failed. <BR><BR>As I stated in a previous message, this is not 
shipping code and can be<BR>easily modified.&nbsp; The IPP Server code is a 
different story, though.<BR><BR>&gt; <BR>&gt; <BR>&gt; NOTE: that the 
'any-value' out-of-band value with a non-zero length field<BR>is<BR>&gt; only 
defined so far for the new Get-Printer-Supported-Values operation.<BR>&gt; Does 
limiting it to this purpose help with the backwards compatibility<BR>&gt; 
problem?<BR>&gt; <BR>&gt; However, it could be used in any 
&quot;xxx-supported&quot; attributes to indicate<BR>that<BR>&gt; validation is 
not performed on that attribute (something Carl Kugler<BR>&gt; mentioned a need 
for certain servers that just want to store away or<BR>forward<BR>&gt; jobs 
without validating them).&nbsp; When used for this purpose, it might 
then<BR>be<BR>&gt; used in a Set-Printer-Attributes operation to configure 
an<BR>&quot;xxx-supported&quot;,<BR>&gt; so it could go in the client to server 
direction. But again the<BR>&gt; Set-Printer-Attributes is a new 
operation.&nbsp; The only problem with existing<BR>&gt; client or server code 
would be a client that did a Get-Printer-Attributes<BR>&gt; requesting 
&quot;xxx-supported&quot; where it might get back the 'any-value'<BR>&gt; 
out-of-band value.&nbsp; But what would such a client (like yours) do?<BR>&gt; 
Hopefully, not crash.&nbsp; If the client quietly skips over the value field 
as<BR>&gt; with any other attribute value, then there shouldn't be any problem, 
even<BR>&gt; with this use of 'any-value'.<BR>&gt; <BR>&gt; But in any case, we 
need to be very careful not to define things that will<BR>&gt; break existing 
implementations, hence this mail thread.<BR>&gt; <BR>&gt; Comments?<BR>&gt; 
<BR>&gt; Thanks,<BR>&gt; Tom <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; -----Original 
Message-----<BR>&gt; From: Ron Bergman [] 
<BR>&gt; Sent: Thursday, March 09, 2000 10:08<BR>&gt; To: Hugo Parra<BR>&gt; Cc:; <BR>&gt; Subject: Re: IPP&gt; OPS - Ok 
that the 'any-value' out-of-band value hasan<BR>&gt; attribute value?<BR>&gt; 
<BR>&gt; <BR>&gt; All,<BR>&gt; <BR>&gt; In the IPP 1.1 Protocol document, the 
paragraph cited<BR>&gt; by Hugo goes on to read...<BR>&gt; <BR>&gt; 
&quot;However, the definitions of additional &quot;out-of-band&quot;<BR>&gt; 
values in future documents are able to explicitly use the value field<BR>&gt; 
and have a value-length that is non-zero, if there is a need for<BR>&gt; 
additional information to be associated with the out-of-band value.<BR>&gt; 
Unless the definition of an &quot;out-of-band&quot; value explicitly allows for 
a<BR>&gt; value, the value-length MUST be 0 and the value empty.&quot;<BR>&gt; 
<BR>&gt; So a 1.1 implemetation must not break, but a 1.0 might.<BR>&gt; 
<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Ron Bergman<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 
Hitachi Koki Imaging Solutions<BR>&gt; <BR>&gt; <BR>&gt; Hugo Parra 
wrote:<BR>&gt; <BR>&gt;&nbsp; All, Our current client implementation (Novell's 
IPP Gateway) checks<BR>&gt; that all &quot;out of band&quot; attributes have 
value lengths of zero.&nbsp; This<BR>&gt; code hasn't yet been officially 
released, so it's still possible to<BR>&gt; change it, if needs be.&nbsp; But 
make no mistake, allowing non-zero values<BR>&gt; for &quot;out-of-band&quot; 
values does break the current IPP rules.&nbsp; Section<BR>&gt; 3.10 of the 
&quot;IPP/1.0: Encoding and Transport&quot; document reads: &quot;If a<BR>&gt; 
value-tag contains an &quot;out-of-band&quot; value, such as 
&quot;unsupported&quot;, the<BR>&gt; value-length MUST be 0 and the value empty 
&amp;mdash; the value has no<BR>&gt; meaning when the value-tag has an 
&quot;out-of-band&quot; value.&quot; -Hugo<BR>&gt;<BR></DIV></BODY></HTML>