Subject: IPP> MOD - ISSUE: # of octets of 'text'/'name' SHALL a Printer support?

From: Tom Hastings <[email-masked]>
Date: Mon, 20 Oct 1997 17:18:23 PDT

Our current Model text gives upper bounds on the lengths of the 'text' and
'name' attributes as 4095 and 255 octets, respectively.  However, we don't
say how many of those octets a Printer object SHALL store.  We also don't
say what happens if a client supplies a value that is longer than
the maximum size that a Printer supports.

These are two issues that will affect interoperability.

I suggest that we add two sentences something like:

A Printer object SHALL support at least nnn octets in requests and responses.
If a client supplies a value that exceeds nnn, the Printer object SHALL
truncate the value on the right after the nnn-th octet.

I propose that 'nnn' be 255 for text and 127 for names.  UTF-8 takes about
1.7 octets per character on average for Western European names.

Comments?  Lets discuss at Wednesdays telecon.

Thanks,
Tom

Here is the current text:

4.1.1 'text'

The 'text' attribute syntax is a sequence of one or more characters with a
limit of 1 to 4095 octets.  The Printer object SHALL support UTF-8 [28] and
MAY support additional charsets provided that they are registered with IANA
[54].

...

4.1.2 'name'

The 'name' attribute syntax is the same as 'text', including the MANDATORY
support of UTF-8 and the exception natural language mechanism, except that
the sequence of characters is limited so that its encoded form is of length
1 to 255 octets.  This syntax type is used for user-friendly strings, such
as a Printer name, that, for humans, are more meaningful than identifiers.  

...

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 20 Oct 1997 18:01:22 PDT

Hmmm,

Tom seems to have worked in other standardization projects than I have.
In messaging and directory standards the meaning of an upper bound limit is
that all implementations have be able to handle it if they get a text
string of that length (without truncating it). Only if the upper limit is
exceeded, it might be truncated by the receiving side, or alternatively a
protocol error might be returned.

Hence in my view the upper bound values ARE the length that the Printer
object SHALL be able to store.

My 2 cents.

Carl-Uno

>as a Printer name, that, for humans, are more meaningful than identifiers.  
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Tom Hastings <[email-masked]>
Date: Tue, 21 Oct 1997 07:48:53 PDT

To make the discussion more concrete on the length (text=4095, name=255 
octets), here are the attributes in IPP/1.0 that are involved:

The 'text' and 'name' attribute involved are:

                                         Supplied by client?
Operation Attributes:
document-name (name)                     Yes

Job Attributes:
job-name (name)                          Yes
job-originating-user (name)              Yes
job-state-message (text)                 No
job-message-from-operator (text)         No (at least not in V1.0)

Printer Attributes:
printer-name (name)                      No
printer-location (text)                  No
printer-info (text)                      No
printer-make-and-model (text)            No
printer-state-message (text)             No
printer-message-from-operator (text)     No (at least not in V1.0)

So far the initial reaction (Don and Carl-Uno) is that the full length is 
intended to be supported by the Printer object.  Fine with me if we agree 
to that.

The reason that I brought up the issue, is that in SNMP the MAX length is
separate from the MIN required for conformance.  So we need to discuss
and clarify the document.  Else we will have some interoperability
problems.

Tom