Callers:
Roger
Scott
Keith
Jay
Bob
Randy
Proposed Agenda
1. Conformance
2. Best-effort
3. One Job URL vs 3 Job URLs discussion
4. Remaining Austin Issues
5. Plans for for a new draft soon (according to IETF guidelines)
6. Firm up plans for a one day face to face (Wed, 5/14 in San Diego
prior to the Thurs IPP PWG meeting)
Discussion
1. We reviewed Roger's email and Tom's
(http://www.pwg.org/hypermail/ipp/1264.html) and Scott's responses.
Generally there is much agreement with the specifics that Tom proposed.
There is some concern that Tom's proposed the use of "supported" for
values which are "implemented" is inconsistent with "supported values
vs. ready values". Roger will merge his original text, with sections from
the document, with Tom's responses, and identify only the remaining
issues, not the ones we have already agreed to. Bob will help with
words about "multiple-documents-are" semantics.
2. We discussed the notion of Mandatory attributes. These are attributes
that clients must implement and printers must implement. Scott proposed
that this set be limited to:
job-url, job-name, job-state, job-state-reasons, job-state-as-text,
document-name, (??document-url, document content), printer-url,
printer-name, printer-state, printer-state-reasons, printer-state-as-text.
All other attributes will fall into the general rules about attributes that may
or may not be implemented on either client or server sides.
3. We want IPP to be extensible. However, the current model (since
there is no requirement) does not have the notion of "self-describing
attributes and syntaxes" That is, conforming clients don't have to worry
about getting a new attribute from a Printer that it has never seen before,
and then on-the-fly determining the value syntax, multi-valuedness, and
so on. The good news is that the protocol mapping being proposed for
IPP shows a simple string based encoding of the protocol so that in
reality, all "values" in the encoded protocol are strings. The client could
do some processing of these (convert from a string representation of an
integer to a real integer) as it chooses.
4. Prior to Austin, the best-effort tag was moved to be a best-effort
attribute at the job level. At Austin, there was some discussion about
moving it back to an attribute-by-attribute tag. However, in today's
discussion, we realized that best-effort on an attribute-by-attribute tag
basis is trying to model an interactive process that is not being done by
almost any print system that exists today and, at best, is being marginally
implmeneted in emerging "leading edge" print systems. Therefor, the acid
test for best-effort is: What is being done today? If it were on an
attribute-by-attribute tag basis, would anyone really know or care to use
it? The consensus of our discussion today was NO! It is only really
useful on a blind submit (no prior query) which often is not interactive
anyway. There was idea that innovative enhancements could be made
to run over an IPP protocol with a model that did not include best effort on
every attriute with some special additional holding mechanisms. The take
away is to leave best-effort as it stands - a job level attribute.
5. Are there any solutions that worry about fonts requested and fonts
supported and font substitutions? Roger responded that in the IBM
production print arena these are the major issues. However, the IPP
model does not currently model font-substitution negotiation at job
submission time. There are no Job Template attributes that involve fonts.
In other words, best-effort doesn't apply to fonts in our current model
anyway. There is only a Printer Behavior attribute that will indicated
which font-substitutions are supported. Proposal: take out this printer
attribute.
6. We discussed one Job URL vs 3 Job URLs. Randy will supply more
details about his proposal for 3 based on our security discussion (see
below). Impact: more than one url must be a tagged url -
ADD_DATA:url_1, QUERY:url_2, CANCEL_MODIFY:url_3, EXTENTION_A:
url_4, etc. There was no decision or consensus on this issue.
7. One reason for multiple job URLs is to expose or allow for multiple
security schemes (different for each URL or class of operations).
However, for job submission, there must be authentication, although
might be very weak, if there is to be any security later. How can you
require that only the job submitter be allowed to cancel a job if the Printer
does not know who the job submitter is? We allow for the term
Authorization to include even weak forms (I claim to be "scott", you trust
that claim even though anybody could claim to be "scott" I don't have to
prove anything, I just have to assert it). This works inside of trusted,
secure domain areas.
8. In a non-secure environment, the Printer could respond to a Print
Request will some sort of print authorization cookie. This could then be
used for later authentication and authorization ("You submitted the job,
so any time you want to query or cancel, pass this back to me to prove
you are the submitter") This works well when there is no overall
security mechanism in place set by administrative policy, but it puts a
burden on the client to manage the returned cookie.
9. Bob made a proposal to change from "one attribute does all (tags,
default, supported, ready, etc.)" to "an attribute in the Print Request/Job
object" and corresponding "supported" and "default" attributes in the
Printer. ISSUE: What about availability ("ready"/"not-ready")? Two ways
to solve this: 1) Yet another Printer attribute suggesting the ready values
(ala DPA) or 2) a complex data value supporting a ready tag. This
proposal would allow us to get rid of all tags! If we remove the
"embedded" tags then we loose the ability to support a client telling a
printer both "what the job is" and "what is wanted or how to process the
job" Consensus was that it is ok to loose this ability (for client to supply
both what is and what is wanted) because, again, of the acid test: who
is doing this now and will they use it in IPP? The answer to that is NO.
10. We do plan to meet, Wed, 5/14 in San Diego. Need to confirm with
Patrick that we have a place.
Notes taker:
Scott Isaacon