Empty values (and unspecified attributes) in IPP

Empty values (and unspecified attributes) in IPP

Empty values (and unspecified attributes) in IPP

Tom Hastings hastings at cp10.es.xerox.com
Fri Nov 22 18:03:52 EST 1996


I've discussed the problem of whether to allow empty values 
in single-valued and multi-valued attribtes with Carl-Uno.


We both think that it is too "tricky" and "confusing" to allow empty
values in either job attributes (and Job Template attributes) and
printer attributes.  Seeing a distinguished value that means none,
such as "none", makes it much clearer and simpler to implementors
and users alike than when there is an explicit no value.


We believe that all syntaxes that are lists (start with #) should
have a 1 in front, meaning that at least one value shall be supplied
by the end-user for job attributes in the Print operations and by the
system-administrator for Job Template and Printer attributes.


If the submitter omits a job attribute entirely, then and only then, will
the Job Template value be used.  


Therefore, we suggest that all attributes that are a list have
a 1 added before the #, so that at least one value must be supplied.


I have indicated under each one whether there is a need for
a distinguished value to be added, suggested what it is
or whether the spec already has such a value.


I've also indicated some wording changes so that the semantics will
agree with the syntax.


For some printer attributes, there is already the phrase:
If this attribute is not specified or is empty, then the effect is that
no ... is supported.


So for a number of the Printer attributes we don't need a distinguished
value for no support.  The Printer object omits the attribute all together.
In most cases, the semantics was already written this way, so all we need
to do is to delete the "or empty" from the sentence describing the semantics
of what to do when the printer attribute is not specified.


I've also discovered a few (number-up and finishing) that need
"none" as a distinguished value.


Tom




6.2.4.6 job-state-reasons (1#type2Enum)	26
Need to add "none" and remove the sentence:
It is valid for the printer to set the value of the job state reasons
attribute to the empty set.




6.2.6.1 notification-events (#type1Enum)	27
Make 1#.  Already has "none" value and semantics correctly specified




6.2.8.2 number-up (positiveInteger)
Needs to be a type3Enum with standard values: "none", "1", "2", and "4".




6.2.8.3 finishing (type2Enum)
Already has "none" as a value, but it should probably be moved from
the end of the table to the beginning.




6.2.10 Job Resource Attributes (Set by the program that produces or senses
the PDL)	37
6.2.10.1 document-format-used (1#type2Format)	38
Ok as is.  No "none" needed




6.2.10.2 fonts-used (1#string)	38
Ok as is.  No "none" needed




6.2.10.3 code-sets-used (1#type3Enum)	38
Ok as is.  No "none" needed




6.2.10.4 media-used (1#type2Enum)	38
Ok as is.  No "none" needed






6.4 Printer Attributes (Set by the Administrator)	41
6.4.9 notification-events (#type2Enum)	45
Make 1#.  Already has "none" value since it uses the values of 6.2.6.1
notification-events.  However, delete the "or empty" in the following 
sentence:


If the attribute is unspecified or empty, the Printer does not perform
notification, though the Printer still checks the jobs' notification-events
attribute.


(Or since we already have a distinguished none value, we could delete
the entire sentence).


(Actually, we may have agreed to delete this attribute since it has
to do with notifying operators, not job-submitters).




6.4.10 notification-addresses (#name)	45
Make 1#.  We don't need a distinguished value; if the notification-addresses
printer attribute is missing, there is no operator notification.
Also delete the "or empty" in the following sentence:


If the attribute is unspecified or empty, the Printer does not perform
notification, though the Printer still checks the jobs' notification-events
attribute.


(Actually, we may have agreed to delete this attribute since it has
to do with notifying operators, not job-submitters).




6.4.11 end-user-acl (#name)	45
Make 1#.  We don't need a distinguished value; if the end-user-acl
printer attribute is missing, there is no restrictions on access.  
Also delete the "or empty" in the following sentence:


If the attribute is unspecified or empty, the Printer allows anyone to print.




6.4.13 fonts-substitutions (#stringPair)	45
Make 1#.  And add sentence:


If the attribute is unspecified, the Printer does not perform
any font substitutions.




6.4.14 fonts-supported (1#stringState)	46
Ok as is.  "none not needed.




6.4.15 media-supported (1#nameState)	46
Ok as is.  "none" not needed.




6.4.16 document-formats-supported (1#type2FormatState)	46
Ok as is.  "none" not needed.




6.4.17 numbers-up-supported (1#positiveIntegerState)	46
Needs to change data syntax to (1#type3EnumState)
and refer to number-up attribute for the values (which I propose
above to have a "none").




6.4.18 finishings-supported (#type2EnumState)	46
OK as is.  Already has "none" value.




6.4.19 sides-supported (1#type2EnumState)	47
Ok as is.  "none" not needed.
  


6.4.20 print-qualities-supported (1#type2EnumState)	47
Ok as is.  "none" not needed.
  


6.4.21 printer-resolutions-supported (1#positiveIntegerCrossState)	47
Ok as is.  "none" not needed.
  


6.4.22 code-sets-supported (1#type3EnumState)	47
Ok as is.  "none" not needed.
  


6.4.23 off-peak-times-supported (#type3EnumState)	47
Make 1#.   "none" not needed, because the semantics already has the 
sentence:
If this attribute is unspecified, then the Printer has no off-peak periods.  




6.4.24 events-supported (#type2EnumState)	48
Ok as is.  Has a "none" value and has the sentence:


If this attribute is unspecified, then the Printer does not support
notification.  




6.4.25 locales-supported (1#type3LocaleState)	48
Ok as is.  "none" not needed.




6.4.26 job-sheets-supported (#type3EnumState)	48
Ok as is.  Has a "none value.




6.4.27 maximum-copies (positiveInteger)	48
Ok as is.  Has two ways to indicate no limit:


If the attribute is unspecified or has a value of 0, there is no limit 
on the maximum number of copies for this Printer.


Do we really want to have the 0 value mean no limit?  Or just the
absence of the maximum-copies printer attribute.  Lets be consistent
and not have any "magic" values that don't mean the obvious thing.


So delete the "or has a value of 0," in the following sentence:


If the attribute is unspecified or has a value of 0, there is no limit 
on the maximum number of copies for this Printer.




6.4.28 maximum-job-octets (positiveInteger)	48
Delete the "or has a value of 0," in the following sentence:


If the attribute is unspecified or has a value of 0, there is no limit on
the size of a job in octets.




6.4.29 maximum-impressions (positiveInteger)	49
Delete the "or has a value of 0," in the following sentence:
If the attribute is unspecified or has a value of 0, there is no limit on
the size of a job in impressions.




6.4.30 maximum-media-sheets (positiveInteger)	49
Delete the "or has a value of 0," in the following sentence:
If the attribute is unspecified or has a value of 0, there is no limit on
the size of a job in media-sheets.




6.4.31 maximum-job-retention-period (deltaTime)	49
Ok as is.  Doesn't have the "or has a value of 0,"




6.4.32 maximum-end-user-priority (type1Enum)	49
Ok as is.  Doesn't have the "or has a value of 0,"




Comments?
Tom



More information about the Ipp mailing list