This proposal was agreed to at the telecon, 10/15/97. We believe that this
proposal meets the IETF Character Set and Language Policy. This proposal
does not use RFC 2184 tags, changing a decision we made at the 9/17/97
Atlanta meeting. Instead, it uses an approach which does not require any
extra information in attribute values for conforming implementations. Only
if an implementer chooses to support the OPTION of allowing the charset
and/or natural language to be different amongst attributes in the request
or in the response is there additional information passed in the attribute
value to indicate the different charset and/or natural language. Finally,
most of the complexity here is for an implementation that supports multiple
charsets and/or multiple languages in 'text' and 'name' attributes.
Implementations that support only a single charset or language can avoid
most of this complexity.
The text changes to incorporate this are straightforward to make in the
text changes of the Model document dated 10/14/97. Please send any
comments ASAP, while we are writing up the exact text changes, if you see
any problems.
The 'text' and 'name' attribute involved are:
Operation Attributes:
document-name (name)
Job Attributes:
job-name (name)
job-originating-user (name)
job-state-message (text)
job-message-from-operator (text)
Printer Attributes:
printer-name (name)
printer-location (text)
printer-info (text)
printer-make-and-model (text)
printer-state-message (text)
printer-message-from-operator (text)
The following attributes are described in the proposal:
Operational Attributes:
operation-charset
operation-natural-language
Job Attributes:
job-charset
job-natural-language
Printer Attributes:
printer-charset
printer-charset-supported (no "s" to agree with Job Template)
printer-natural-language
printer-natural-language-supported (no "s" to agree with Job Template)
All other IPP Job and Printer attributes are of other attribute syntaxes
and so are not affected by this internationalization proposal.
Each numbered point applies to both charset and natural language. Points
with "a" are just charset and points with "b" are just natural language.
Here are the major points of the simplification:
1. Support of the UTF-8 charset is MANDATORY for all 'text' and 'name'
attributes supported by the Printer object. Support for additional
charsets is optional, but if supported, SHALL be as specified below.
2. The client SHALL supply the "operation-charset" and
"operation-natural-language" attributes in the operations attribute group
in every request. These attributes indicate the charset and natural
language of the 'text' and 'name' attributes being supplied in the request.
The "operation-charset" also identifies the charset that the Printer SHALL
use in the response. The "operation-natural-language' attribute identifies
the natural language that the Printer SHOULD use in the response.
3. On the create job operations, the Printer object SHALL store the values
of the client-supplied "operation-charset" and "operation-natural-language"
attributes as the values of the "job-charset" and the
"job-natural-language" Job Description attributes, which clients may query.
4. The Printer object SHALL return the "operation-charset" and
"operation-natural-language" attributes in the operations attribute group
in every response. These attributes indicate the charset and natural
language of the 'text' and 'name' attributes being returned in the response.
5. Change the spec to NOT pass the "operation-charset" and
"operation-natural-language" attributes via HTTP/1.1 header and
"Content-Type", but just as other IPP operation attributes.
6a. A Printer object SHALL reject an operation that supplies an unsupported
charset value in the "operation-charset" operation attribute with the error
code ??? (new one or use some existing one?).
6b. A Printer object SHALL either (1) accept an operation that supplies an
unsupported natural language in the "operation-natural-language" operation
attribute or reject the operation with the error code??? (new one or use
some existing one?), depending on implementation.
NOTE: THE REMAINING POINTS ONLY APPLY TO IMPLEMENTATIONS THAT SUPPORT MORE
THAN ONE CHARSET OR MORE THAN ONE NATURAL LANGUAGE. THEREFORE, THE
FOLLOWING COMPLEXITY IS NOT A BURDEN TO ALL IMPLEMENTATIONS.
7a. A response MUST be in the same charset as the request. The Printer
"printer-charset-supported" attribute SHALL list the charsets supported by
the Printer object which SHALL contain at least the value 'utf-8'. If the
Printer object supports more than just the 'utf-8' charset, the Printer
object SHALL be able to code convert between each of the codesets supported
on a highest fidelity possible basis. However, some information loss MAY
occur curing the codeset conversion depending on the charsets involved.
For example, the Printer object may convert from a UTF-8 'a' to a US-ASCII
'a' (with no loss of information), from an ISO Latin 1 CAPITAL LETTER A
WITH ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a UTF-8
Japanese Kanji character to some ISO Latin 1 error character indication
such as '?', decimal code eqivalent, or to the absence of a character,
depending on implementation.
NOTE to client implementors: When submitting a request, if your client
passes a small charset, such as US-ASCII, in the "operation-charset"
operation attribute, you may lose information since the Printer will be
constrained to return the response in US-ASCII.
7b. A Printer SHOULD do its best to respond in the same natural language.
The Printer "printer-natural-language-supported" attribute SHALL list the
natural languages supported. For any of the attributes for which the
Printer generates messages, i.e., for the "job-state-message" and
"printer-state-message" attributes in operation responses and
notifications, the Printer object SHALL be able to generate messages in any
of its supported natural languages. If the Printer object supports neither
the "job-state-message" nor the "printer-state-message" attribute, then the
"printer-natural-language-supported" NEED NOT be implemented or MAY have
the same (single) value as the "printer-natural-language" attribute.
The description for each 'text' and 'name' attribute, including future
registration proposals, SHALL specify whether the Printer object MUST
support its value in all supported natural languages or not.
For other Printer 'text' and 'name' attributes supplied by the operator,
system administrator, or manufacturer, i.e., for "printer-name" (name),
"printer-location" (text), "printer-info", and "printer-make-and-model"
(text), the Printer object is only required to support the configured
natural language of the Printer identified by the Printer's
"printer-natural-language " attribute, though support of additional natural
languages for these attributes is permitted.
For the 'name' and 'text' attributes supplied by the client, i.e.,
"job-name" (name) and "job-originating-user" (name), the Printer object MAY
indicate the natural language that the client supplied using the method
described in 9b (below).
If the client requests a natural language that is not supported, the
Printer object SHALL return the "job-state-message" and/or the
"printer-state-message" in the Printer's configured natural language as
specified by the Printer's "printer-natural-language " attribute.
8a. Each job MAY have been submitted with a different charset. For the
Get-Jobs operation response, the Printer object SHALL return 'text' and
'name' attributes in the charset requested by the client in the
"operation-charset" operation attribute. This requirement may cause the
Printer object to codeset convert the 'text' and 'name' attribute data to
the charset requested by the client using the "highest fidelity" technique
described in 7a above.
8b. Each job MAY have been submitted with a different natural langauge.
For the Get-Jobs operation response, the Printer object SHALL include the
job's "job-natural-language" as the first attribute returned for each Job
object for each Job object which is in a different natural language than
the Printer returned in the "operation-natural-language" operation attribute.
9a. We considered that the client did not need to pass in "exception"
charset attribute values and the Printer is constrained to return all
'text' and 'name' in a single charset, so we don't need a way to identify a
different charset for an attribute value than the one passed in the
"operation-charset" operation attribute.
9b. If the client needs to pass or the Printer object needs to return a
'text' or 'name' attribute in a different natural language than the rest of
the 'text' and 'name' attributes in the request as indicated by the
"operation-natural-language" operation attribute, the client or Printer
object may immediately precede that attribute value with a
'naturalLanguage' attribute value that indicates the differing natural
language. Thus the attribute becomes multi-valued.
If the attribute is multi-valued (1setOf X), then the 'naturalLanguage'
value applies only to the next 'text' or 'name' value. Subsequent 'text'
and 'name' values revert to the natural language of the operation attribute
or the "job-natural-language" job attribute, if present in the case of a
Get-Jobs response.
If the client supplies a 'naturalLanguage' attribute value that is NOT one
of the supported natural languages, the Printer SHALL either (1) reject the
request with error code ??? or accept the unsupported natural language,
depending on implementation.
10. ISSUE: Need to determine how to pass charset and natural language
information in the notification content. We could continue to use the RFC
2184 tags as currently specified. Another idea is to pass additional
charset and natural language attributes that affect the immediately
following attribute. Still another approach would be to change the
Notification Content into an application/ipp notifiy operation request and
use the encoding from the protocol. The simplest approach would be only to
provide for human readable notification in IPP/1.0 and add software
processable notifications after V1.0. Then such human readable
notification would be in the charset and natural language supplied in the
create operation. The format in the Model document could become just an
example.
Again, please send any comments ASAP, while we are writing up the exact
text changes, if you see any problems.
Thanks,
Tom