IPP> MOD - Updated simplified internationalization proposal

IPP> MOD - Updated simplified internationalization proposal

Tom Hastings hastings at cp10.es.xerox.com
Wed Oct 15 15:31:52 EDT 1997


This is a slightlty updated and further simplified proposal from the one
sent out last night changing:


point 4a to recommend, rather than require, charset conversion, but ALL
'text' and 'name' attributes in the response SHALL be returned in a single
charset, which is either the requested charset or the charset of the Job or
Printer object.


4b to specify that the language returned is either the requested language
or the language of the Job or Printer object, but ALL 'text' and 'name'
attributes in the response SHALL be returned in a single natural language,
which is either the requested natural language or the natural language of
the Job or Printer object.


and adding point 5 to return the charset and natural language being
used in the response for each job (since they could be different) in
Get-Jobs Response.






Modified proposal:


This proposal is a simplification of the IPP internationalization proposal
that Ira and I put out on Monday, 10/13/97 and that Bob and Ira responded
to via e-mail.  Bob, Ira, and I collaborated on this one.  We believe that
this proposal meets the IETF Character Set and Language Policy.  


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' 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)


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 RFV 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 all requested 'text' and 'name'
attributes in a single charset.  That charset SHALL either be (1) the one
requested by the client in the request via the "content-charset" operation
attribute or (2) the charset of the Job or Printer object.  The Printer
object SHALL return the "content-charset" operation attribute indicating
the charset of the returned 'text' and 'name' attributes.  The response 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,
if performed, is 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 all requested 'text' and 'name'
attributes in a single natural language.  That natural language SHALL
either be: (1) the one requested by the client in the request via the
"content-natural-language" operation attribute or (2) identified by the
natural language of the Job or Printer object.  The natural language of the
Job object is the one supplied by the "content-natural-language" in the
create operation.  The natural language of the Printer object is its
"natural-language-default" attribute: 


    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, if the
Printer supports the "job-state-message" and/or the "printer-state-message"
attributes.  


    B. 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 is only required to support
the default natural language of the Printer identified by the Printer's
"content-natural-language-default" attribute.  


    C. For other Job '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 whether the Printer object MUST
support its value in all supported charsets and natural languages or not.  


To help the client determine the single natural language being used for all
'text' and 'name' attribute returned in each operation response, the
Printer object SHALL return the actual natural language being used as the
value of "content-natural-language" operational attribute.


5. In the Get-Jobs operation response, each Job's charset and natural
language may be different, so the response SHALL include the
"content-charset" and the "content-natural-language" in the returned Job
attributes. 


6. 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.


7a. Require that a Printer object support the UTF-8, ISO 8859-1 (ISO
Latin1), and US-ASCII charsets, to facilitate inter-working.


7b. No particular natural languages are required for a Printer object to
support.


8. 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.


9. 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.


10. 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.


Thanks,
Tom



More information about the Ipp mailing list