Gail,
This is a bug in the IIG, RFC 3196. There is no
'client-error-natural-language-not-supported', since the Printer MUST accept
any natural language in a request, whether it supports that natural language
or not.
RFC 2911 section 3.1.4.1, says:
The IPP object MUST accept any natural language and any Natural Language
Override, whether the IPP object supports that natural language or not (and
independent of the value of the "ipp-attribute-fidelity" Operation
attribute). That is the IPP object accepts all client supplied values no
matter what the values are in the Printer object's
"generated-natural-language-supported" attribute. That attribute,
"generated-natural-language-supported", only applies to generated messages,
not client supplied messages. The IPP object MUST remember that natural
language for all client-supplied attributes, and when returning those
attributes in response to a query, the IPP object MUST indicate that natural
language.
So the two references to client-error-natural-language-not-supported in RFC
2911 should be deleted. I'll post an addendum to RFC 2911, using the
regular IETF procedures for addendum.
FYI, to find RFC Errata, go to:
http://www.rfc-editor.org/rfcsearch.html
and click on the RFC Errata button on the top line.
BTW, I submitted a minor errata on RFC2911 on July 17, and it hasn't been
posted yet. I don't know why. See the IPP mailing list which I copied.
Tom
-----Original Message-----
From: Gail Songer [mailto:gsonger at peerless.com]
Sent: Monday, July 08, 2002 13:14
To: Hastings, Tom N
Subject: client-error-natural-language-not-supported
Hi Tom,
I've been reading the 1.1 implementors guide in detail recently, and came
across the status return code of
"client-error-natural-language-not-supported". (section 3.1.2.1.6,
docuement-natural-language). I can't seem to find this anywhere else. Am
I going crazy?
Gail