There was a:
IPP Model Teleconference
2/14/97
2:00 - 4:00 PM MST
I have uploaded the minutes files to
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/970214-minutes.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/970214-minutes.docftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/970214-minutes.txt
Below is a copy.
Scott
************************************************************
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
************************************************************
IPP Model Teleconference
2/14/97
2:00 - 4:00 PM MST
Attendees:
Scott Isaacson
Randy Turner
Carl-Uno Manros
Bob Herriot
Jim Walker
Item 1:
Internationalization. At the model and semantics level, we should just
identify all attributes as having some generic syntax (such as "url",
"type1Enum", "string", etc.) All attributes of type string could be in most
any character set with any encoding. We have to be at least as rich as
what 10646 defines. There are 2 attributes which are already defined in
the model that help clients and "printers" interoperate using the IPP
operations "user-locale" and "printer-locale" The "encoding" of these
strings in the give protocol mapping will be defined in each mapping
document. For example, an HTTP/1.1 mapping might allow for these
strings to be encoded differently (more capable) than HTTP/1.0. At this
level we put in the attributes that are necessary to allow for localization
and for negotiation, but we don't worry about encoding. We also
discussed UTF-8 and UTF-7. Bob pointed out UTF 7 needs about 1.5
bytes (on average) for Engish characters where as UTF-8 needs about
1.13 bytes per character. Also, UTF-7 can be as high as 2.5 for other
language sets.
Item 2:
Each Printer object and each Job object has the following:
An identifier which will be a URL
A name which is just as string (see item 1 above).
The URL is unique and conforms to the rules for URLs. A name need not
be unique and is just a string. A Printer Name is probably in the directory
for lookup based on Name and then the URL is retrieved. These
attributes (URL and Name) are attributes of the object iteself and can be
returned in Get Attribute operations. The same attributes (URL and
Name) will be used for both Job objects and Printer objects; that is there
will not be different Name attributes for Jobs and Printers as in a
"job-name" attribute AND a "printer-name" attribute. They are more like
"common" attributes for Jobs and Printers. Documents will have neither
URL nor Name attributes.
Item 3.
The Print Response will only have Job URL coming back, NO printer
status or job status. We need to keep each operation semantically simple
- no overloading of separate semantic operations onto one IPP operation.
So we will remove Job Status and Printer Status from the Print
Response. Also, on the Print Request, we will remove the "Requested
Attributes". If a real status operation is needed, it can be performed
separately.
Item 4:
We discussed the need for more operations given the new talk of a
model that allows for submitting attributes "before" submitting document
content. At this high level of Model and Semantics we assume the
following rules:
A Print Request consists of :
Job Attributes (possibly empty)
Document 1 Attributes (possibly empty)
Document 1 Content (URL, octet string, etc)
Document 2 Attributes (possibly empty)
Document 2 Content (URL, octet string, etc)
*
Document Last Attributes (possibly empty)
Document Last Attributes (possibly empty)
All Job attributes come BEFORE Documents
All Document attributes come BEFORE document content
However, we could issue one lower level protocol operation with just
Job Attributes and get back a Job URL. Then issue additional protocol
operations to get more document attributes and document contents to the
Printer. This is very close to what Roger outlined in his proposal for the
lower level protocol operations. If the Printer does not support Long
Jobs or Jobs spread out over multiple protocol operations then it could
return a fail error code on the first protocol operation with the more bit
set to true; it might require the whole thing in one protocol operation.
Item 5:
Take out the Job Status from the Cancel-Job return (see simplifying goals
in item 3).
Item 6:
In this version of the document List Jobs has been merged in with Get
Attributes. As in item number 3 above, separate this back out. Also, we
still need to look at whether or not "Get Attributes: Job Templates" needs
to be a separate operation also. Maybe this will be more clear as we
map this model (and operations) to the scenarios. Note: There is a typo
on allJobsLong and Short. Two of those should say allMyJobsLong and
Short.
Item 7.
Since Job-Hold-After and Job-Print-After etc are not extremely critical
features for IPP/1.0 and since they are taking a lot of time and energy
away from more productive work, we will drop these from IPP/1.0 If
there are scenarios that need them, lets go back and look at the
scnearios and change the scenarios.
Item 8:
The same (see Item 7) is true for page-select. Remove it from IPP/1.0.
Item 9:
An attribute called "unspecified-production-attributes" was added to this
version. The recommendation is that we take out the attribute, but leave
the text in a general area to describe better the semantics of the model
and what end users and admins might expect if there are NO production
attributes.
Item 10:
Bob H. will continue editing the doc to make one more pass based on
today's discussion and hopefully have it ready by 2/19 IPP telecon.
Item 11:
Scott will start to look at model vs scenarios
Item 12:
A reminder to Tom H that he took the action item at the 2/6 IPP meeting at
Adobe to look at IPP attributes vs Printer MIB and Job Monitoring MIB
objects.