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

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

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

Tom Hastings hastings at cp10.es.xerox.com
Mon Oct 20 20:18:23 EDT 1997

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.


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


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.  


More information about the Ipp mailing list