SM> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec

SM> RE: IPP> 4 significant proposed increases in conformance requirem ents for the IPP Document object spec

McDonald, Ira imcdonald at
Fri Apr 18 14:34:17 EDT 2003

Hi Michael,

Tom's notes are actually incomplete.  A conforming implementation
MUST support at least one scheme (I suggested we RECOMMEND that
'http:'), but an administrator _at_run_time_ may choose to disable
this feature by reconfiguring "reference-uri-schemes-supported".

I proposed making this operation (Send-URI) mandatory.  But only
if ALL implementations MUST support at least one reference scheme
and SHOULD support 'http:' (note that PSI servers MUST support
'http:' for the AddDocumentByReference method).  

I contend that the burden of adding a minimal HTTP client to an
existing IPP-based printer is minimal.  That's the question.

- Ira McDonald

-----Original Message-----
From: Michael Sweet [mailto:mike at]
Sent: Friday, April 18, 2003 6:50 AM
To: Hastings, Tom N
Cc: sm at; ps at; ipp at
Subject: Re: IPP> 4 significant proposed increases in conformance
requirements for the IPP Document object spec

[My initial comments; I still haven't finished going through the
document object spec, so I may have more comments early next week]

Hastings, Tom N wrote:
> ...
> 1. Change the Send-URI operation and the corresponding 
> "reference-uri-schemes-supported" (1setOf uriScheme) Printer
> Description attribute from OPTIONAL to REQUIRED for a Printer to
> support.  We agreed that a conforming implementation MAY have an
> empty list for the "reference-uri-schemes-supported" Printer
> Description attribute.

So in essense you are just changing the status code from
server-error-operation-not-supported to

> Reason:  PSI requires this operation (and has no OPTIONAL
> attributes). Optional operations are much less likely to get support
> by clients.  It is best practice for an OPTIONAL extension
> specification (such as this spec) to have no OPTIONAL operations, so
> that user clients will receive the same level of service from all
> Printer implementations that support this extension.

This reasoning makes no sense since you are also saying that
"reference-uri-schemes-supported" can be an empty list, which
means that you still have no service from an implementation that
doesn't really support Send-URI.

Also, I still question the usefulness of Send-URI and Print-URI
since security issues (authentication and access control) make
implementation for non-trivial URIs difficult, if not impossible.

> 2. Change the Set-Document-Attributes operation from OPTIIOAL to
> REQUIRED for a Printer to support.

OK, however I think the state <-> status table (table 5) isn't
right - what if you want to restart a job but print only 1
copy of the first document?

> 3. Change the Set-Job-Attributes operation from OPTIONAL to
> RECOMMENDED for a Printer to support.
> Reason: To go along with the change in the conformance requirements
> for the Set-Document-Attributes operation.  However, don't REQUIRE 
> Set-Job-Attributes, since most of the interesting attributes are
> document attributes, not job attributes.

Hmm, I'll have to review the current spec some more, but I don't
remember a section on Set-Job-Attributes in the March 24th draft.

Any chance you can post a message to the *IPP* list whenever you
put a new draft up please?  Also, it might be helpful to know when
you plan on doing telecons - it can be difficult to schedule the
time, but I *do* attend them occasionally...

(I didn't get messages about either on the IPP list)

> 4. Add an OPTIONAL 'guaranteed" value (see [ippsave] section 8.1) for
> the "pdl-overrides-supported" Printer Description attribute (REQUIRED
> in [rfc2911] section 4.4.28) to augment 'not-attempted', and
> 'attempted' values.  Also add a REQUIRED
> ...

OK, no problem with this.

Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX             

More information about the Sm mailing list