I posted
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970502-model-minutes.txt
Below the text is included:
Minutes of the 5/2/97
Model Teleconference
2-4 pm Mountain
Attendees:
Roger deBry
Jim Walker
Jay Martin
Scott Isaacson
Peter Zehler
Keith Carter
Tom Hastings
Bob Herriot
Note taker: Scott Isaacson
Agenda
1. Mandatory attributes were proposed in the 2.1 version of the document.
There has been no comment on these. Review, and comment.
2. Since we are getting rid of tags, it is not acceptable to live with the
ambiguity as clarified by Tom in last weeks minutes. That is xxx-supported
values are: 1) client desires to
override the PDL (the same instruction is in the PDL) or 2) client desires
action only when the information is not in the PDL. This was once being
solved by the embedded and embedded-only tags. Since we have no tags, the
proposal is to define a set of xxx-capable attributes to go along with the
xxx-supported attributes. Jim Walker took an action item to write this up
can clarify semantics of xxx-supported, xxx-capable and best-effort and
embedded instructions in PDL.
3. compression is currently in the Job Templates section. It makes no sense
to have a "default" compression value as a printer attribute.
4. There is some value to have a document-format default attribute at the
printer object. Bob suggested the reason, but I lost it in my notes.
5. We do not need a number-of-documents-completed attribute.
6. locale-supported will go into the operation headers rather than be
negotiated as a Printer attribute.
7. scheduling-algorithm stays but it is single valued (it is not
scheduling-alorithms-supported which can come later).
8. We reviewed Keith and Roger's proposal. Seems to be general agreement to
move the multiple write operations up into the model document. Jim
suggested that if we do, we need to consider a new state that shows the
"being built" nature of the job rahter than just relying on a
printer-state-reason of incomplete. However, it was pointed out, this
suggestion is independent of the new operations proposal and applies to the
existing model semantics as well. New issue: Should we have an additional
job state?
In reviewing the propsal, it became clear that this protocol could use byte
ranges rather than "first", "middle", "last", "only" in order to help with
some sending recovery problems (you get to the second to last packet of a 5
Mb job and have to start over if there are no byte ranges at all). Rules
are: ranges must be in order (no gaps) but ranges can overlap (backwards).
Each range has a FIRST, LAST, TOTAL. Total must be given on the last
packet. It may be given on non last packets, and if it is, it could go up
on the next packet but never down. If it is not known, it need not be
given. By definition, when last == total (take into account 0 indexing)
then it is the last packet for a document.
Valid Examples
First-Last, Total
Example 1:
0-99
100-199
200-299,300
Example 2:
0-99
80-199
200-299,300
Example 3:
0-99,300
100-199,300
200-299,300
Example 4:
0-99,200
100-199,250
200-299,300
Example 5:
0-99,100
Invalid examples
Example 1:
0-99
200-299
100-199,300
Example 2:
0-99,150
100-124,125
Example 3:
0-99,150
<nothing else>
There was a suggestion to use a "last doc" flag in the send-doc rather than
introduce a whole new end-job operation.
9. We are waiting for more work from the security team.
10. We do not need to introduce a read/write tag now (in order to be ready
for future modify operations) since a simple work around could be introduced
later which is an attribute which is a list of writeable attributes. The
assumption NOW is that no attributes are writable.
11. Don Fullman at Xerox put together a table showing the relationship of
tags to attributes. This table will become something like:
xxx xxx-supported (Y/N), xxx-capable(Y/N), xxx-available(Y/N), etc.
12. To fix Tom's notes from last week, there is no xxx-ready proposed. Just
an optional xxx-available. If xxx-supported is multi-valued, then so it
xxx-available. For each value in xxx-supported, there is a corresponding
value in xxx-available, which shows is state of readiness. If xxx-available
is not implemented, then all xxx-supported values are assumed to be ready.
Scott