Subject: [IPP] Opinions needed: xxx-default, xxx-ready, and xxx-supported

From: Michael Sweet <[email-masked]>
Date: Mon, 23 Jan 2012 15:31:07 -0800

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.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Paul Tykodi" <[email-masked]>
Date: Tue, 24 Jan 2012 06:00:41 -0500

Hi Mike,

In terms of supporting the shift away from depending upon a driver always
being available for every imaging device brought to market, I think the xxx
attributes class becomes very important because it allows an imaging device
to advertise its capabilities and its current status to a client using a
technique from a published set of standards.

I think your proposal is helpful in this regard and I do not see any
negative outcomes to making the proposed changes.

Thanks.

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked]
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
Sweet
Sent: Monday, January 23, 2012 6:31 PM
To: [email-masked]
Subject: [IPP] Opinions needed: xxx-default, xxx-ready, and xxx-supported

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?

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

---

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 24 Jan 2012 04:45:48 -0800

Mike,

I support your proposal.  It also clarifies the mapping between IPP and
the Semantic Model.

Pete

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Sweet
Sent: Monday, January 23, 2012 6:31 PM
To: [email-masked]
Subject: [IPP] Opinions needed: xxx-default, xxx-ready, and
xxx-supported

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

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?

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean.

---

From: Ira McDonald <[email-masked]>
Date: Tue, 24 Jan 2012 12:39:49 -0500

Hi Mike,

I also support your proposal - a good clarification
of an originally confusing aspect of IPP/1.1 spec.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Jan 24, 2012 at 7:45 AM, Zehler, Peter <[email-masked]>wrote:

> Mike,****
> the Semantic Model.****
> Pete****
> ** **
> ** **
> Webster NY, 14580-9701 ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Michael
> Sweet
> *Sent:* Monday, January 23, 2012 6:31 PM
> *To:* [email-masked]
> *Subject:* [IPP] Opinions needed: xxx-default, xxx-ready, and
> xxx-supported****
>
> ** **
>
> All,****
>
> ** **
>
> inconsistencies in the next update of the registry.****
>
> ** **
>
> 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.****
>
> ** **
>
> (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)****
>
> ** **
>
> always contain values that can be used in the corresponding xxx Job
> Template attribute...****
>
> ** **
>
> MY PROPOSAL****
>
> ** **
>
> Printer attributes, not Job Template).****
>
> ** **
>
> hide the corresponding definitions.****
>
> ** **
>
> Comments?****
>
> ** **
>
> ________________________________________________________________________**
> **
>
> Michael Sweet, Senior Printing System Engineer, PWG Chair****
>
> ** **
>
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>