Subject: [IPP] Some feedback on IPP System Service

From: Michael Sweet <[email-masked]>
Date: Fri, 09 Jun 2017 16:36:40 -0400

All,

I spent some time today assembling the IANA considerations for this spec and have some feedback for discussion:

- All of the printer-id/ids attributes have a range of 1:MAX, but the originally proposed limits were 1:65535 since the discovery protocols printer-id is getting used with can only provide 16 bits of information.  We should either a) change the range of supported values to 1:65535 or b) clearly document these limits (like we have for printer-device-id and other attributes that sometimes exceed the range supported by particular protocols/interfaces) so that implementors can plan accordingly.  (I am somewhat in favor of approach B since there are some existing IPP solutions that support more than 64k of print queues...)

- "requesting-user-vcard (1setOf text(1023))" and "system-device-id (text(1023))" can just be MAX (MAX = 1023 for text values) or have no limit specified at all.

- "printer-creation-attributes-supported", "resource-settable-attributes-supported", "system-mandatory-attributes-supported", and "system-settable-attributes-supported" should all be "1setOf keyword" (no type2) since we don't register values for these kinds of keyword attributes (which refer to registered or vendor-extension attribute names).

- The "system-configured-resources" collection does not include "resource-state-reasons", which would seem to be important.

- The "ipp-features-supported" attribute should be added to the System Description attributes.

- Why is the "system-state-message" attribute a 1setOf?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

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

---

From: Ira McDonald <[email-masked]>
Date: Fri, 16 Jun 2017 14:23:06 -0400

Hi Mike,

Thanks very much for the review and comments.  Inline in BLUE

Cheers,
- Ira

On Fri, Jun 9, 2017 at 4:36 PM, Michael Sweet <[email-masked]> wrote:

> - All of the printer-id/ids attributes have a range of 1:MAX, but the
> originally proposed limits were 1:65535 since the discovery protocols
> printer-id is getting used with can only provide 16 bits of information.
> We should either a) change the range of supported values to 1:65535 or b)
> clearly document these limits (like we have for printer-device-id and other
> attributes that sometimes exceed the range supported by particular
> protocols/interfaces) so that implementors can plan accordingly.  (I am
> somewhat in favor of approach B since there are some existing IPP solutions
> that support more than 64k of print queues...)
>

ira - my mistake - I'll correct to the 16-bit range

>
> - "requesting-user-vcard (1setOf text(1023))" and "system-device-id
> (text(1023))" can just be MAX (MAX = 1023 for text values) or have no limit
> specified at all

> .
ira - agree - will fix to MAX (I prefer explict limits)

>
> - "printer-creation-attributes-supported", "resource-settable-attributes-supported",
> "system-mandatory-attributes-supported", and "system-settable-attributes-supported"
> should all be "1setOf keyword" (no type2) since we don't register values
> for these kinds of keyword attributes (which refer to registered or
> vendor-extension attribute names).
>

ira - don't understand what you mean by "(no type2)" - do you mean the
actual
type should be "1setOf type1 keyword" or that even type3 (deprecated) were
legal - in the IANA Registry, job-creation-attributes-supported is has
actual type
"1setOf type2 keyword" (i.e., an explicit type2) - is that one wrong?

>
> - The "system-configured-resources" collection does not include
> "resource-state-reasons", which would seem to be important.
>

ira - my mistake - will fix.

> - The "ipp-features-supported" attribute should be added to the System

ira - my mistake - will fix.

> - Why is the "system-state-message" attribute a 1setOf?

ira - my mistake - I followed Pete's System Service (5108.06) where it's a
list.
I'll change it to single-valued like Printer and other objects in IPP.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 16 Jun 2017 16:10:31 -0400

Ira,

> On Jun 16, 2017, at 2:23 PM, Ira McDonald <[email-masked]> wrote:
> ...
> ira - don't understand what you mean by "(no type2)" - do you mean the actual
> legal - in the IANA Registry, job-creation-attributes-supported is has actual type

No, just:

    printer-creation-attributes-supported (1setOf keyword)
    resource-settable-attributes-supported (1setOf keyword)
    etc.

And yes the registry is wrong (I've actually fixed a few of them before, looks like I missed that one).

The issue is that by marking it as "type1" or "type2" then we are signing up for maintaining a registry of values; in the past some have just used:

    job-foo-supported (1setOf type2 keyword)
      < any Job Template attribute >

some have listed the names explicitly, and some list *both* - we haven't been consistent.

Because attribute and member names use the keyword syntax, and since these attributes list attribute or member names, they don't need explicit registration unless we want to include the attribute semantics ("list of Object Name attributes") in the registry...

My preference is to simplify the registry where possible, and in doing so I get to remove special-casing from the IPP-to-SM generator... :)  Another bonus is that software the might validate the values of those attributes against the registry will continue to work in the presence of unregistered vendor values.

Alternately I'd like to normalize all of these attributes and their registrations so that a) we are consistent and b) the IPP-to-SM generator can generate something more useful.

---

From: Ira McDonald <[email-masked]>
Date: Fri, 16 Jun 2017 18:48:55 -0400

Hi Mike,

Thanks - I figured out your rationale after I sent that reply.

FYI - when I looked in my local copy of most recent IANA IPP Registry
updates today, *all* of the existing "xxx-attributes-supported" had an
infix of "type 2", so we need to globally check for and fix in the next
IANA update.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
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]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Jun 16, 2017 at 4:10 PM, Michael Sweet <[email-masked]> wrote:

> > - "printer-creation-attributes-supported",
> "resource-settable-attributes-supported", "system-mandatory-attributes-supported",
> and "system-settable-attributes-supported" should all be "1setOf keyword"
> (no type2) since we don't register values for these kinds of keyword
> attributes (which refer to registered or vendor-extension attribute names).
> >
> The issue is that by marking it as "type1" or "type2" then we are signing
> up for maintaining a registry of values; in the past some have just used:
>
> Because attribute and member names use the keyword syntax, and since these
> attributes list attribute or member names, they don't need explicit
> registration unless we want to include the attribute semantics ("list of
> Object Name attributes") in the registry...
>
> My preference is to simplify the registry where possible, and in doing so
> I get to remove special-casing from the IPP-to-SM generator... :)  Another
> bonus is that software the might validate the values of those attributes
> against the registry will continue to work in the presence of unregistered
> vendor values.
>
> Alternately I'd like to normalize all of these attributes and their
> registrations so that a) we are consistent and b) the IPP-to-SM generator
> can generate something more useful.
>