The text changes to incorporate this are straightforward to make in the
text changes that I sent out on 10/13/97.
We'd like to discuss this at the Wednesday, 10/15/97 1:00-3:00 pm PDT telecon.
The 'text' and 'name' attributes 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)
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. Instead of using RFC 2184 charset and natural language tags in each
attribute of type 'text' or 'name', require that all 'text' and 'name'
attributes in a single operation request or operation response (including
multiple Jobs in a single Get-Jobs response) be in the same charset. For
each 'text' and 'name' attribute specify whether the natural language SHALL
be as the client requested, the Printer's default, or that supplied by the
client that created the Job.
Eliminating the charset and natural language tags makes it easier to
support legacy systems, and also allows direct support of charsets that do
not have US-ASCII as a subset, such as ISO 10646/Unicode/UCS-2 (which NT,
Java, and Novell directories support). In the future, if it becomes
necessary to support more than one charset or natural language in an
operation request or response, then we can do one of any: (1) add new
'taggedText' and 'taggedName' attribute syntaxes which do use the RFC 2184
tags, (2) use dictionaries, or (3) Bob's scheme in his e-mail that splits
the charset/language into one value and the rest in a separate value.
2a. Continue to require the client to supply the "content-charset"
operation attribute in the request to unambiguously identify the charset
for all 'text' and 'name' attributes in the request or response. This
meets the IETF character set and language policy.
MINOR ISSUE: Ask Harald whether the charset policy would allows us to
specify that omission of the "content-charset" operation attribute could be
defined to be identical to supplying a value of 'utf-8' or not.
2b. Allow the client to supply the "content-natural-language" operation
attribute in order to indicate the natural language of all 'text' and
'name' attributes that the client is supplying. If omitted, the Printer
object shall behave as if the client had supplied the Printer's
"natural-language-default" attribute value. Omission of
"content-natural-language" is allowed in requests by the IETF character set
and language policy.
3. For the create operations, the Printer object shall store the
content-charset" and "content-natural-language" attributes supplied by the
client in the Job object for use in subsequent event notifications.
4a. A Printer object SHALL respond with 'text' and 'name' attributes in the
charset identified by the client in the request and SHALL return the
"content-charset" operation attribute with the same value. This may
require the Printer object to code convert from one of its supported
charsets to another one of its supported charsets. Such a code conversion
is performed on a 'best efforts' basis and may result in some loss of
information. For example, the Printer object may charset 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.
4b. A Printer object SHALL respond with 'text' and 'name' attributes in the
natural language (1) identified by the client in the request, (2)
identified by the Printer's "natural-language-default" attribute, or (3)
the natural-language supplied by the client that created the Job object,
depending on the attribute as follows:
A. For 'text' and 'name' attributes generated by the Printer object,
i.e., for "job-state-message", "printer-state-message", the Printer is
required to generate attributes in all of the supported languages
identified by the Printer's "natural-language-supported" attribute.
B. For 'text' and 'name' attribute supplied by the operator, system
administrator, or manufacturer, i.e., for " job-message-from-operator"
(text), "printer-name" (name), "printer-location" (text), "printer-info",
and "printer-make-and-model" (text), the Printer SHALL only support the
default natural language of the Printer identified by the Printer's
"natural-language-default" attribute..
C. For 'name' and 'text' attributes supplied by the client, i.e.,
"job-name" (name) and "job-originating-user" (name), the Printer object
stores the supplied "content-natural-language" with the Job object (as long
as it is one of the Printer's supported natural languages identified by the
Printer's "natural-language-supported" attribute).
The description for each 'text' and 'name' attribute, including future
registration proposals, SHALL specify which other attribute identifies the
natural language of the attribute as indicated above.
To help the client determine the natural language of each 'text' and 'name'
attribute returned in each operation response, the Printer object SHALL
return the "content-natural-language" with the same value
and the Printer's "content-natural-language-default" as operational
attributes.
NOTE - In the Get-Jobs operation response, each Job's natural language may
be different, so the client will have to explicitly request the
"content-natural-langauge" Job attribute in order to determine the natural
language of the "job-name" and "job-originating-user" Job attributes.
5. The Printer object SHALL identify the supported charsets and natural
languages in its "charset-supported" and
"content-natural-language-supported" Printer attributes that it is capable
of accepting in requests and returning in responses as described above.
6a. Require that a Printer object support the UTF-8, ISO 8859-1 (ISO
Latin1), and US-ASCII charsets, to facilitate inter-working.
6b. No particular natural languages are required for a Printer object to
support.
7. If a client supplies a value for the "content-charset" or
"content-natural-language" operation attribute that is not supported by the
Printer object, the Printer SHALL reject the request and return error code
???. Otherwise, the Printer object might have to perform a code conversion
to an unknown (or at least unsupported) charset.
8. Leave "content-charset" and "content-natural-language" attributes as Job
Template attribute, but put a "No" in the default column for
content-charset-default, since there isn't a default attribute.
9. Don't pass the "content-charset" and "content-natural-language"
operation attributes as HTTP/1.1 header and "Content-Type", but just as
other IPP operation attributes. Therefore, rename them to
"attribute-charset" and "attribute-natural-language" Job Template attributes.
Please send comments before the telecon, if possible.
Thanks,
Tom