Subject: IPP> Teleconference call minutes

From: "Whittle, Craig" <[email-masked]>
Date: Thu, 1 May 2008 13:14:09 -0700

All:

The minutes from this week's teleconference call can be found at:
ftp://ftp.pwg.org/pub/pwg/ipp/ippv2-minutes/IPPv2-ConCall-Minutes-200805
01.pdf 

The next teleconference is scheduled two weeks from today (same time).

Best regards,
 
**CW

---

From: Michael R Sweet <[email-masked]>
Date: Thu, 01 May 2008 13:57:50 -0700

> The next teleconference is scheduled two weeks from today (same time).

My apologies for not calling in - I had a minor emergency at home and
had to babysit the repairman...

In response to the meeting minutes:

* Why would CUPS make all IPP optional operations in v2.0 “C or ‘not
   necessary’”? Could this be because they are “not necessary” for an
   IPPv1.1 compliant implementation.

If we go with my proposal of the v2.0 being a simple workgroup
printer, the optional operations are not necessary, and if you look
at the mailing list archive much of the feedback from the participants
at that time was to make these operations optional *because* they
were not feasible to implement in a workgroup printer with limited
memory and CPU, and generally no disk space.

My proposal from Februrary has v2.0 including/supporting RFC 2910 and
2911 and PWG 5100.1, 5100.2, and 5101.1.  The only addition I might
make to that list would be RFC 3382 (collection attributes) so that
printers accept/understand collection attributes, even if they are
ignored - right now many IPP/1.0 and IPP/1.1 printers will reject
whole requests with collection attributes rather than returning a
successful-ok-ignored-or-substituted-attributes status.

If IPP 2.x is supposed to define one or more standard "profiles" of
IPP support, then it makes sense to have a baseline 2.0 which has a
minimum number of operations and attributes that need to be supported
(good for that embedded/workgroup printer implementation) while
ensuring that all of the basic attributes, tags, and values are
defined and supported at that level (good for compatibility going
forward.)

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer