IPP Mail Archive: IPP> MOD - Updated Model sections for internationalization

IPP> MOD - Updated Model sections for internationalization

Tom Hastings (hastings@cp10.es.xerox.com)
Mon, 13 Oct 1997 10:32:39 PDT

I've posted .doc, .txt, .pdr (red rev revision), and .pdf (black revision
marks) for the updates to the IPP Model document with the
internationalization proposal Ira and I sent out last Tuesday that we
agreed on in
principle at the last Wed telecon on:

ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/md9709ct.*

(ct for cut versions, since it only contains the sections that I
changed for I18N in the 9/26/97 Model document.)

The .txt is without any revision marks. Its 28 pages, so I haven't
attached it to this mail message.

The .pdf and .pdr files with revision marks are 24 pages long.

I tried real hard not to repeat anything, but to use cross-references
instead.

Please send any comments before the IPP telecon, this Wednesday, 1-3pm PDT.
We'll discuss this on the telecon as well.

Here is the first 4 pages of the 28-page text version of the file:

Subj: IPP Model with those section changed for Internationalization
From: Tom Hastings
Date: 10/10/97
File: md9709ct.doc

This file contains only the modified sections cut from the Model
document affected by the internationalization agreements that Ira and
I proposed on 10/7/97 and were agreed to writeup on the 10/8/97
telecon. Therefore, there are some cross references to sections that
are not in this cut version of the document. Please disregard them.
They are the same as in the 9/26/97 version and will re-appear when
this cut version is merged in with the rest of the document.

The Table of Contents contains only the sections that are included in
this document, i.e., only the sections that are affected by the
proposal. The revision marks in the Table of Contents show what
sections have been added or deleted and which section headings have
been changed.


Table of Contents

3.1.3 MANDATORY Charset and Natural Language Operation Attributes 4
3.2.1.1 Print-Job Request 7
3.2.5.1 Get-Attributes Request 8
3.2.5.2 Get-Attributes Response 9
3.2.6.2 Get-Jobs Response 10
3.3.1.1 Send-Document Request 10
3.3.3.2 Cancel-Job Response 11
4. OBJECT ATTRIBUTES 12
4.1 Attribute Syntaxes 12
4.1.1 'text' 13
4.1.2 'name' 13
4.1.3 'keyword' 14
4.1.4 'enum' 15
4.1.5 'uri' 15
4.1.6 'uriScheme' 15
4.1.7 'charSet' 15
4.1.8 'naturalLanguage' 16
4.1.9 'mimeType' 16
4.1.10 'octetString' 17
4.1.11 'boolean' 17
4.1.12 'integer' 17
4.1.13 'rangeOfInteger' 17
4.1.14 'dateTime' 17
4.1.15 'resolution' 18
4.1.16 '1setOf X' 18
4.2 Job Template Attributes 18
4.2.1 job-sheets (type4 keyword, name) 24
4.2.2.1 Event Notification Content 24
4.2.5 job-hold-until (type4 keyword, name) 25
4.2.7 media (type4 keyword, name) 26
4.2.16 document-format (mimeType) 27
4.2.21 content-charset (charSet) 61
4.2.22 content-natural-language (naturalLanguage) 28
4.3.5 job-originating-user (name) 45
7. INTERNATIONALIZATION CONSIDERATIONS 29
9. REFERENCES 31

1.

2.
3.

3.1

3.1.1

3.1.2

3.1.3 MANDATORY Charset and Natural Language Operation Attributes

Some of the Job and Printer attributes have values that are text
strings and names intended for human understanding rather than machine
understanding. See the 'text' and 'name' attribute syntax
descriptions in Sections 4.1.1 and 4.1.2. Consequently; the following
MANDATORY operation attributes are defined for use in every operation
request:

"content-charset" (charSet):

This is a MANDATORY Job Template attribute (see Section 4.2) for
the client to supply and the Printer object to support. The
"content-charset" attribute identifies the charset that the
Printer object SHALL use for any 'text' and 'name' attributes
that the Printer object generates in the operation response, such
as "job-state-message", unless the Printer object does not
support that charset. In such a case, the Printer object SHALL
use the charset specified by the Printer's "content-charset-
default" attribute instead, rather than returing an error, and
SHALL prepend an explicit non-empty charset tag identifying the
default charset being used in each such generated attribute
value.

This attribute also identifies the charset that SHALL be implied
by any 'text' and 'name' attribute values with an empty charset
tag supplied by the client.

In create operations, the Printer object SHALL store with the Job
object (1) the "content-charset" attribute and (2) any explicit
attribute value charset tags, whether the Printer object supports
the identified charset or not, rather than returning an error.

See the 'charSet' attribute syntax description in Section 4.1.7
for the syntax of this attribute and example values.

The Printer object SHALL support the 'utf-8' charset [28]. For
conforming IPP Printer objects, the 'utf-8' charset value used in
this attribute SHALL be restricted to mean conformance level 2 of
ISO 10646 [48], so that accented letters SHALL NOT be represented
with non-spacing accents. Support of additional charsets in
'text' and 'name attribute values is OPTIONAL, but all supported
charsets SHALL be ones in which the code points from decimal 20
to 127 are US-ASCII [56].



"content-natural-language" (naturalLanguage):

This is a MANDATORY Job Template attribute (see Section 4.2) for
the client to supply and the Printer object to support. The
"content-natural-language" attribute identifies the natural
language that the Printer object SHALL use for any 'text' and
'name' attributes that the Printer object generates in the
operation response, such as "job-state-message", unless the
Printer object does not support that natural language. In such a
case, the Printer object SHALL use the natural language specified
by the Printer's "content-natural language-default" attribute
instead, rather than returing an error, and SHALL prepend an
explicit non-empty natural language tag identifying the default
natural language being used in each such generated attribute
value.

NOTE - A Printer object that support multiple natural languages,
often has separate catalogs of messges, one for each natural
language supported.

This attribute also identifies the natural language that SHALL be
implied by any 'text' and 'name' attribute values with an empty
natural language tag supplied by the client.

In create operations, the Printer object SHALL store with the Job
object: (1) the "content-natural language" attribute and (2) any
explicit attribute value natural language tags, whether the
Printer object supports the identified natural language or not,
rather than returning an error.

See the 'naturalLanguage' attribute syntax description in Section
4.1.8 for the syntax of this attribute and example values.

For the sake of brevity in this document, the above operation
attribute descriptions are not repeated with every operation request.

In addition, the above operation attributes are defined for use in
every operation response with the following definitions:

"content-charset" (charSet):

This is a MANDATORY Job Template attribute for the Printer object
to return. This attribute specifies the charset used by 'text'
and 'name' attributes with empty tags in this response and SHALL
be the same value as supplied by the client in the request,
whether the Printer object supports that value or not. Any
'text' or 'name' values in this response that have a different
charset SHALL have a fully specified charset tag pre-pended to
each such attribute value.

In a subsequent query request (Get-Attributes or Get-Jobs), the
Printer object NEED NOT convert any 'text' or 'name' attribute
values that had been supplied in the original create request to
the charset of the requester when it is different from that
specified (and stored) in the original create request for the
requested attribute. In such cases, the Printer object SHALL
return an explicit charset tag pre-pended to each such attribute
value. See the 'text' attribute syntax description in Section
4.1.1.



"content-natural-language" (naturalLanguage):

This is a MANDATORY Job Template attribute for the Printer object
to return. This attribute specifies the natural language used by
'text' and 'name' attributes with empty tags in this response and
SHALL be the same value as supplied by the client in the request,
whether the Printer object supports that value or not. Any
'text' or 'name' values in this response that have a different
natural language SHALL have a fully specified natural language
tag pre-pended to each such attribute value.

In a subsequent query request (Get-Attributes or Get-Jobs), the
Printer object NEED NOT convert any 'text' or 'name' attribute
values that had been supplied in the original create request to
the natural language of the requester when it is different from
that specified (and stored) in the original create request for
the requested attribute. In such cases, the Printer object SHALL
return an explicit natural language tag pre-pended to each such
attribute value. See the 'text' attribute syntax description in
Section 4.1.1.


For the sake of brevity in this document, the above operation
attribute descriptions are not repeated with every operation response.

NOTE - In the mapping of IPP over HTTP/1.1, the "content-charset" and
"content-natural-language" operation request and response attributes
are conveyed in the protocol via the HTTP/1.1 "Content-Language"
header and the 'charset' parameter of the 'application/ipp' media type
"Content-Type" header [23]. That is, these Job Template attributes
SHALL not be encoded in the 'application/ipp' body. In other mappings
of IPP operations onto some other transport mechanism, these two
attributes will by conveyed using some other mechanism. IPP Printer
objects NEED NOT support HTTP/1.1 Accept headers and IPP/1.0 does not
address the processing semantics for HTTP/1.1 Accept headers in order
to simplify the specification of the IPP semantics.