All,
I have noticed an inconsistency for how we register xxx-default, xxx-ready, and xxx-supported attributes, and how these attributes are documented in our specifications. I would like to clean up these inconsistencies in the next update of the registry.
Typically the xxx-default attributes are included either in the definition and description of the Job Template attributes or in a table at the beginning of the Job Template attributes. xxx-default attributes are part of the Printer Description attributes (printer-attributes-tag) in the protocol but are registered in the Job Template section.
xxx-supported attributes are defined in either the Job Template or Printer Description sections of our specifications, and then have be registered in (usually, but not always) the same sections of the registry. The most common convention is to place xxx-supported in the Job Template section when it contains values that can be used directly and in the Printer Description section otherwise (for example, when xxx-supported provides a list of member attributes that can be specified in the xxx Job Template attribute - media-col works this way)
Finally, xxx-ready attributes are randomly placed in the Job Template or Printer Description sections of our specifications and the registry. They always contain values that can be used in the corresponding xxx Job Template attribute...
MY PROPOSAL
1. Move all xxx-default, xxx-ready, and xxx-supported attributes in the registry to the Printer Description section where they belong (they are Printer attributes, not Job Template).
2. Make sure that JPS3 and all future IPP specs going forward define any Printer Description attributes in that section; no more subsections (or inline text or tables) for xxx-default and xxx-supported that only serve to hide the corresponding definitions.
Comments?
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20120123/8d628e51/attachment-0001.html>