Here is the text version of the minutes I posted to the FTP server
IPP Model Group Minutes
3/3/97
11:00 AM - 1:00 PM (MST)
Attendees:
Scott Isaacson
Peter Zehler
Jim Walker
Tom Hastings
Carl-Uno Manros
Keith Carter
Bob Herriot
Robert Chancellor
Discussion Items:
1. Issue 71: We discussed the idea of returning the Job Status attribute
group in the Print operation response. The full proposal is in 2/24 meeting
notes including Tom's recent email message. Bob will put the new full
new version in 1.5. The issues is not being closed not, but will be after a
review of 1.5. The basic proposal is to add "printer-stopped" and
"printer-partially-stopped" to job-state-reasons enum list. Now that I think
about it, is "printer-stopped" with a tag of "WARNING" rather than
"CRITICAL" the same semantics as "printer-paritally-stopped".
2. Issues 3, 21, 65: Peter Z. will write up the summary of the discussion
on his two proposed attributes - one for "more info" and one for "driver
install" Peter will give some examples how these might be used, but they
will not be formally defined (values that is) at this point. Also, we might
need two "more-info" attributes needed: 1 for site specific and 1 for
vendor hook to vendor on line support info.
3. In order to have a better separation between model and protocol, we
will take out all specific syntax examples in the model spec. That is if an
attribute is of type STRING we will not impose usage of things like ":" as
a delimiter. All of these exact encodings should come in the protocol
spec. Scott fix these in the text.
4. There is a new locale/codeset/language proposal from Tom and Bob.
It is not quite ready for prime time, but coming to theaters near you soon.
The basic idea is to combine all useful triplets into a type3Enum. Since
relationships between values of these three columns are important, bring
each relevant combination into a single enum. Each row of the triplet
table becomes a single value in this type3enum attribute. There still might
be some issues with clients needed to pick out a single local subvalue
from this enum?
5. In order to solve the compliance issues, we will wait until we have
finalized on the set of attributes. All clients need to support all Enum
types, but not all server have to support sending all enum values. For
example, in printer state, if the printer does not implement a given state
value, it does not have to generate it for a state it will never be in. The
client needs to understand that type2 and type3 Enums are extensible,
and they might receive back a enum value that they are not expecting.
6. Issue 21: Attended/Unattended. This will be moved into the "more info"
page rather than add an attribute (boolean) to declare if this instance is
attended by an operator or not. The reason for this is that end users
need this info, not programs, so put in it the more-info page rather than
the protocol.
7. There is still a need to support some sort of print after. Since it is
impossible to default an absolute time and representing NOW as just the
current time is awkward. The idea is to follow the earlier text suggesting
an attribute called "when-to-print" which is just a set of type3enum
representing periods of time (similar to off-peak catagories).
8. We still had a massive discussion on "print during spooling" vs. "model
operations" vs. "synchronous error return". In a real sockets
implemtnation, there is the client writing and a server reading. If there is
a n error at the server, then the server won't read any more, and the
client will get some error on writing. Say, the client tries to write 1K
bytes, and gets a 0 back (couldn't write any). How does this error get
propogated back up the the client app? Is there a channel to get this
back up to the client app? This will have to be discussed in the protocol
working meeting on Friday, 3/7 at 10:30 AM PST.
9. We have not defined error semantics for multiple documents. What if
there are 3 docs, and the second one has an error. Does the printer
print 1 and 3. Does it fail after 2 and not print 3? Can the client give
hints? Is it ONLY based on the implementation?
10. The MODEL team will have weekly meetings, on Fridays at 2:00 PM
MST for 2 hours. There is already a conflict on 3/7, and so there will be
a meeting on 3/6 at 2:00 PM MST.
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************