Michael Sweet wrote:
...
Also, I think we need to explicitly require that IPP servers and
clients be able to handle any value tag, even if it is not
defined in the Model and Protocol documents. Servers and clients
can throw the unknown values away, but can't error out because
they don't understand a value that conforms to the IPP attribute
encoding scheme.
I agree completely. And I think that the Conformance section 5.2.6 of the
Model and Semantics is saying exactly that:
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.
Don't you? The out-of-band values are defined in section 4.1, as are all of
the attribute syntaxes. Thus the fixes that I have suggested in previous
mail messages is just aligning the other parts of the Model and Semantics
document with this paragraph.
Comments?
Tom
P.S. I'm at an off site meeting today (3/15), so I won't be able to call in
for the IPP telecon.