Subject: IPP> MOD - Updated Model sections for internationalization

From: Tom Hastings <[email-masked]>
Date: 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.

---

From: [email-masked] (Robert Herriot)
Date: Mon, 13 Oct 1997 16:03:18 -0700

I have a few comments about Tom's latest document. I have talked with Tom and
we have general agreement about the suggestions below. I agreed to write them up
and send them out to the mailing list.

1) I am still bothered by specifying the syntax of text and name according 
   to RFC 2184, ( charset "'" language "'"). I don't like the idea of
   text and names having a "syntax".  Also, the restriction of text and
   name values to those charsets that has ASCII as a subset bothers me
   -- especially as new systems move toward UCS-2 as the native
   representation.

   I propose a different solution:

    a) separate the charset/language information from the text/name value and put 
       them into separate values, like a multivalued attribute.

    b) For the vast majority of cases where the charset and language of the text/name
       attribute is the same as at the operation level, the charset/language value is
       not needed. So the attribute stays as a single valued attribute, as it was in
       the July draft.

    c) For those rare cases where the language or charset of an attribute differs from
       language and charset specified at the operation level, treat the attribute
       as a pair of values where the first value has a new type "charset/language"
       and the second has a type of 'name' or 'text'.  The first value is in US-ASCII
       and has the syntax of RFC 2184, e.g. "iso-latin-1'de'", and the second value is
       the text/name in the language and charset specified in the first value
       with no restriction on the charset for the text/name value.  If
       either the language or charset field is empty, the value at the
       operation level is inherited.
   
       Note: if we had dictionaries, I would instead propose that text/name values 
       with an overridden charset or language could be a dictionary containing the 
       language and charset overrides along with the text/name value. But we don't 
       have dictionaries yet.

       Note: alternatively, we could also add a special array type consisting of
       n triplets type/value-length/value where there would be three values:
       charset (type "charset", language (type "language") and a text/name value.

    d) This change makes the syntax of all requests and most responses be the same
       as it was before we added the two quotes syntax to text and names.

2) Why isn't content-charset an optional attribute for the client to send?
    
    a) I would prefer that the default for a request and response to be UTF-8
       if no content-charset parameter is present.  
    b) Then there is no need for a printer to have a default-content-charset.
    c) make it a group 1 operation attribute and not an HTTP header. Thus
       rename it 'attributes-charset'

3)  Why isn't content-natural language an optional attribute for the client to send?

    a) I would prefer that the default for a request and response to be the
       server's default natural language.  
    b) Then there is still a need for a printer to have a default-natural-language.
    c) make it a group 1 operation attribute and not an HTTP header. Thus
       rename it 'attributes-natural-language'

4)  If my proposal is accepted, then jobs for most printers are unchanged from the
    July draft by this proposal. They have no operation attributes
    specifying charset or language and the text/name attributes contain
    their value only and have no information about charset and
    language. The default charset UTF-8 and the printer's default
    language are used for all requests and responses. But the mechanism
    is there for full support of charsets and languages if needed.

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Tue, 14 Oct 1997 08:30:32 PDT

Hi Bob,                                        Tuesday (14 October 1997)

I read your note (below) with interest.  I sympathize with your desire
to avoid adding RFC 2184-style "charset/language" tags to the beginning
of all "text" and "name" strings in IPP requests/responses.

It would be REAL helpful if all of the IPP working group members would
take the 20 minutes to read closely and carefully Harald's draft IETF
Policy on Character Sets and Languages.  We could deal with the realm
of acceptable (to the IESG) solutions and not the simpler world we wish
we lived in.

For "text" strings, Harald's draft MANDATES both 'charset' and 'language'
negotiation and tagging permanently.  It SPECIFICALLY precludes a protocol
standard from specifying a default character set OR a default language
in the definition of a parameter or attribute of type "text".  So we
MUST have explicit printer default 'charset' and 'language' attributes.
And due to the requirement for negotiation, we also MUST have explicit
operation attributes for the 'charset' and 'language'.  And if we allow
either a printer object or a job object to have a mixture of 'charset'
or 'language' in their "text" or "name" attributes, then we MUST have
explicit tags in the syntax for "text" and "name" attributes.  If we
don't do this in the drafts of Model and Protocol which we submit to
the IESG, we'll get them back for repair (and we won't finish IPP/1.0
in calendar 1997, as a result).

What we COULD do, is to force ALL of the "text" and "name" attributes
in a request or response to use a SINGLE 'charset' and 'language'.
And require that the 'charset' and 'language' of those attributes be
fixed at job creation time and be ones supported by the target printer
(so that job state reason messages, eg, can be correctly generated by
the printer).

Cheers,
- Ira McDonald (outside consultant at Xerox)

PS - Bob, could you write your messages in a 'narrower' text window?
My mail reader truncates and wraps at 79 columns - lots of your lines
had about 85 columns, so I had to do some 'fixups' to include your note
below.  Thanks.
>--------------------------- Bob's note -------------------------------<
>Date: Mon, 13 Oct 1997 16:03:18 PDT
>From: [email-masked] (Robert Herriot)
>To: [email-masked], [email-masked]
>Subject: Re: IPP> MOD - Updated Model sections for internationalization
>
>we have general agreement about the suggestions below. I agreed to write them
>up and send them out to the mailing list.
>
>    a) separate the charset/language information from the text/name value and
>       put them into separate values, like a multivalued attribute.
>
>       not needed. So the attribute stays as a single valued attribute, as it
>       was in the July draft.
>
>       language and charset specified at the operation level, treat the
>       atrribute