PSI Working Group:
*Alan Berkema *Gail Songer *Dave Hall
*Jerry Thasher Harry Lewis *Ted Tronson
Peter Mierau *Peter Zehler Paul Tykodi
*Bob Taylor Don Levinstone Lee Farrell
Don Wright *Kirk Ocke *Ira Mcdonald
*Amir Shahindoust
* = attendance
07/23/02 Agenda
1) Review psi-spec30.pdf
Minutes:
1) Review psi-spec30.pdf
Ira asked about minutes from the Portland F2F.
Unfortunately we do not have a secratary yet and while
Jim Sommer volunteered he was only able to attend half of
the meeting. He did give his notes for the first half.
I while try to provide an overview of the meeting,
however, most of the real details of the discussion were
captured in psi-spec30.pdf.
We still need a secratary for Santa Fe!
Started out with a review of psi-spec30.pdf, focusing on unfinished work
from the F2F. Since we are aligning with the PWG semantic model
Pete said that he would have a new rev of the document and new schemas
for us to review in Santa Fe.
Next we looked at GetServiceAttributes and exactly what this should return?
This folded into GetSelfDescribingServiceAttributes which we decided
was better named GetServiceAttributeMetaData. Discussion on whether the
return should
be an instance document or a schema and do we need both methods? Can we
align the two
so we do have two different methods with different levels of return values.
Decieded that if we return a Schema we can have only one method and for PSI
1.0 it would
return a Schema with base level attributes. The Schema could be extended
with
Meta Data (self decribing type of features) in the future (beyond PSI 1.0).
What is UPDFs role in this?
How will UPDF harmonize with the semantic model?
Talked about the PSI dependency on the semantic model vs. the PSI schedule.
Decided that the amount of work involved with the semantic model and it's
similar schedule will not add an unreasonable risk to PSI.
Determined that formal notification/eventing methods will not be included in
the PSI 1.0 spec. Could be considered in a following revision.
Security came up again.
The goal of PSI is to facilitate existing security methods by including
credentials
needed by existing methods in appropriate PSI schemas.
We do need to consider privilege roles:
o End User
o Operator
o Administrator
For example we would not want to allow End Users to cancel other users
jobs.
When we reviewed the Target Interface we observed that PostStatus,
PostJobStatus,
PostDocumentStatus are really a lot like a Notifications.
We could call these simple notifications and include a Boolean in CreateJob
that indicates whether or not the notifications were desired.
Formal Notifications, that we decided were post PSI 1.0, would include
Notification subscriptions and Cancel subscription methods that add
complexity.
However if we model our post status as simple notifications then they would
naturally fit with the Formal notifications in the future.
Simple notifications would only be associated with the life of a CreateJob .
Ira took an action to provide information about what IPP uses for
notification payload, things like JobState, JobStateReasons and
various counters. Simple notifications will limit the payload values.
Alan
----
0) Job Control Interface starting to stabilize
Work Remaining Overview:
1) Finalize reference and Target Device Schemas
2) Attributes: PSI has Job, Document, and Processing (template)
Need to help with and leverage the PWG semantic model attributes
3) Discovery, PS and the target Devices a PS knows about?
4) Revisit Target Device Interface
5) Status code, hoping that this will also be part of the PWG
semantic model for leverage
6) Event Notification
7) Security
Finish all that and PSI is done :)
New 6/11/02 Actions:
1) Referenc schema work user name, passwd, certifiacte
and e-mail elements.
Owner: Kirk:
2) Investigate original thougts on time attribute with Bluetooth folks
Owner: Alan
3) Examine Use Models for Job Control interface implemenation
owner: Dave
Thanks,
Alan