The purpose of this note is to clarify several aspects of the
Internationalization sections in the Model and Semantics document dated
November 7, 1997.
1. In lines 675-677, the document states "However, the Printer object's
"natural-language-supported" attribute SHALL list the natural languages
supported by the Printer object and any contained Job objects, so that the
client MAY query which natural language(s) are supported."
In lines 697-704, the document states "The IPP object SHALL accept any natural
language and any Natural Language Override, whether the IPP object supports
that natural language or not ... the IPP object SHALL remember that natural
language for that attribute, and SHALL indicate the natural language when
returning the attribute in response to a query."
Question: Since a Printer object MUST accept and store natural languages that
it does not support for Jobs created with unsupported natural languages, it
seems a client or application can be misled if the Printer object includes
these unsupported natural languages in a query on the attribute
"natural-language-supported" by a Printer. Is this misleading? If so, then I
propose removing the phrase "and any contained Job objects" in line 676.
2. In lines 692-695, the document explains the usage of Natural Language
Override.
Question: What is the compelling rationale and scenario(s) that make this
capability for client requests meet the "80-20 test"? For example, on a client
request does specifying a "job-name" attribute in a different natural language
than "attributes-natural-language" justify this capability? Please clarify.
3. Scenario: The Printer object returns "charset-supported" = UTF-8,
ISO-8859-1 and ISO-8859-7. The Printer object returns
"natural-language-supported" = en (english), fr (french) and el (greek). The
client specifies "attributes-charset" = ISO-8859-1 and
"attributes-natural-language" = el which in combination are invalid.
Question: How does the Printer object handle this situation? I expect the
Printer object rejects the request with a status code of
"client-error-conflicting-attributes".
Question: Does IPP assert that an IPP client will avoid the above situation
based on its knowledge of valid charset and natural language combinations? If
so, then should we state this in the model document?
Because I am not sure how often this situation will occur, I do not want to
design a complex solution but rather document the appropriate behavior of the
client and Printer object in this situation.
4. The following comment is from Gary Miller who is an IBM
Internationalization Architect. Gary is on vacation until 12/1 so I'm sending
this comment on his behalf to make the 11/25 deadline.
Scenario: A server (or printer) supports a charset(s) other than UTF-8 as its
native charset. However, the server has the facilities to map UTF-8 to its
native charset(s) so its Printer objects publicize UTF-8 as the supported
charset. The server is doing the conversion to show these attributes via
non-IPP means such as an operating system Print Object (or maybe a MIB?).
Question: How does such a server know how to convert the text and name
attributes from UTF-8 into its appropriate native charset? Is the
"attributes-natural-language" attribute intended to indicate (in ISO terms)
"the repertoire" (e.g. the characters that make up ISO-Latin-1) of the charset
so the server can make the appropriate conversion? If that is an intent for
the "attributes-natural-language" attribute, then this should be documented in
the model document.
Thanks in advance for your help!
Keith Carter
Senior Programmer
IBM Network Computing Software Division
carterk@us.ibm.com
1-512-838-2155