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.
Cheers,
- Ira McDonald
-----Original Message-----
From: Michael Sweet [mailto:mike@easysw.com]
Sent: Friday, April 18, 2003 6:50 AM
To: Hastings, Tom N
Cc: sm@pwg.org; ps@pwg.org; ipp@pwg.org
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
client-error-uri-scheme-not-supported.
> 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 http://www.easysw.com
This archive was generated by hypermail 2b29 : Fri Apr 18 2003 - 15:26:35 EDT