I will post the minutes from the 2/21 call
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/970221-model-minutes.pdf
The ftp server seems to be rejecting my attempts at logging in. Until then,
included is a txt copy.
There is another call at 3:00 PM Mountain today 2/24. See the other
email.
We also conlcuded the following:
If you want something added to the MODEL issues list, please make a
special note of it in your e-mail by using "ISSUE" or someother signifcant
hint. Also, word issues as you would like to see them on the issues list.
For other, less significant comments on a document review or
something, just include them in the email without calling attention to them
as "ISSUES".
Scott
-------------------------------------------------------
IPP Model Group Meeting Minutes
2/21/97
2:00 - 4:00 PM
Discussion Items:
Agenda turned out to be:
- Review scope and purpose of the Model document
- Review 1.3.1 document and discuss items marked as issues.
- Review new issues lists
2. What is the scope and purpose of the Model document:
There seems to be a lot of details about the attributes and their values
and syntaxes, however there seems to be very little on over all Model
issues. This is due to tht face that we have not done a full edit on the
document. We need to add in some higher level sections on: use of
directory, use of notifications, use of security, and then include some
design goals such as: use of URIs, use of attributes for late binding and
document management, use of attribute adornment, etc. Scott will take
an edit pass on the document once Bob H is done with the attribute
sections.
3. What do printer object supplied defaults mean in relation to embedded
commands in formated documents?
For example, if the printer object default for media is set to some value,
and a job is submitted with no media attributes and the submitted job is
some well formated PDL with embedded commands to select the media
through the interpreter, what is the relationships of all of these values?
Is the embedded command intended to be the definitive answer since the
end user just created the document and that is what they explicitly
requested? Or, did the end user just pull the document off of some
server somewhere and they really want to override the embedded
commands with the printer default values? We did not come to closure
on this issue.
4. Status attributes coming back in the Print Operation?
We still have not closed on: 1) not allowing any status attributes to come
back in the Print response. 2) Allowing only a well known, "hard coded",
fixed set of attributes to come back in the response, or 3) Allow a
general purpose request any attribute to come back in the response.
Some of the issues with option 1 are requireing multiple operations for
info that is generally needed. Some of the issues with option 2 are
supporting attributes from multiple objects in the response and lack of run
time extesibiblity. Some of the issues with option 3 are added complexity
and processing in every operation even if it is used very infrequently.
Tom H will make a proposal.
5. The issue about requesting specific attributes vs requesting groups in
the Get Attributes is resolved. We will allow for the requesting of
specific attributes.
6. Tom H then started to take notes. We agreed to assign a person with
one or more helpers to work on each Open issue. The first name is the
assigned person who will be responsible to contact the others and work
out a solution.
Page 9, line 355: How does a Printer indicate priorities of
defaults: those that override what is in a document and those that do
not? Do we need a tag or an overal policy attribute that affects all
attributes?
Status: Open.
Assigned: Bob H and Tom H.
Page 10, line 378: What should be returned on a Print operation?
Job-state, Queue-position, printer-state, and printer-state-reasons?
Status: Open.
Assigned: Tom H to make a proposal.
Page 11, line 411: Should a client be able to request specific
attributes in a Get-Attributes operation?
Resolution: Yes.
Status: Closed
Page 15, line 498: Are the coded-characters that are specified in
the Model and Semantics standard, abstract or the actual
coded-characters? If abstract, then the protocol standard must specify
the mapping onto actual coded-characters.
Status: Open
Assigned: Roger, Bob H
Page 16, after line 498: version and Page 36, line 1025: Will
document-formats be registered as name and version combined? Or do
we just use the current IANA registration setup for the Printer MIB for
Interpreter Language Families?
Status: Open
Assigned: Tom H, Bob H
Page 16, after line 498: How are different currencies handled, if
we have a cost attribute? While the locale may ofter imply a currency,
there may be circumstances, when a different currency is needed than
that implied by the locale.
Status: Open
Assigned: ???
Page 19, lines 562-563: Do we need a tag to indicate that certain
attribute values are only for indicated document-formats or can setting
up different fan-in Printers (one for each document-format) suffice?
How does auto-sensing of document-formats fit into either solution?
Status: Open
Assigned: Keith C, Bob H, Tom H.
Page 22, lines 632-669: We agreed to abandon having URL and
name attributes that are common to Jobs and Printers. Go back to
job-URL, printer-URL, job-name, and printer-name. The semantics of
each was too different depending on whether the object was Job or
Printer and we only had two such attributes.
Status: Closed
Assigned: Bob H will reformulate as originally but using *URL', instead of
*identifier' in the name of the attribute.
Page 25, lines 740-742: How can the user specify the level of
detail to be sent by the Printer on notifications?
Status: Closed
Agreement: The System Adminstrator specifies which attributes are
returned in notifications. Examples will be added to the document.
Page 25, lines 770-773: How many different values for
job-priority are needed?
Status: Closed
Agreement: Use the same range as ISO DPA: 1-100, so that it is easier
to map to the various print systems that have a number of different
priorities (even though the utility of having a large number may be
questioned). MVS has A-Z, BSD has 1-39, etc.
Page 27, lines 827-828: How do production attributes that conflict
with embedded attributes get resolved and how this conflict resolution is
probably PDL dependent.
Status: Open
Assigned: Bob H and Roger d
Page 30, lines 921-930: Not clear whether the client must specify
input-tray, as well as, or instead of, a medium name? Its listed as
type2EnumPlus.
Status: Closed
Agreement: The user may specify a medium name, a medium size, or an
input tray, but not more than one. Bob H will clarify the text. [Editor's
note: the data type should be changed from type2EnumPlus to
type2Enum, since a client can only specify one value.]
Page 37, lines 1035-1043: Keith suggests adding more text
attributes: font-style, line-numbers, text-border, word-wrap,
number-of-columns, file-name, file-time, file-date. All are Booleans,
except font-style. The group agreed in principle to add these.
Status: Open
Assigned: Keith C, write up actual complete text for each for future
review.
Page 39, lines 1106-1107: Is reverse-landscape and
reverse-portrait needed for content-orientation or should we specify that
the direction of rotation should be whatever is needed by the Printer for
finishing, if finishing is supported.
Status: Closed
Agreement: Instead of specifying the direction of rotation (like ISO DPA),
IPP will only specify that the direction of rotation of landscape is what is
needed for accomplishing finishing, if any is supported. If finishing is not
supported, then the direction of rotation for landscape does not matter
(and will be +90 in some implementations and -90 in others). Bob H to
add more explanation along these lines.
Page 42, after line 1191 and page 43, lines 1200-1204: What
does the printing job-state include? Should the state be called
processing, instead, so that it may cover more than just putting marks on
paper?
Status: Open
Assigned: Bob H, Keith C, Tom H
Page 47, line 1294: Are there too many printer-types listed (from
the Printer MIB which was also copied into ISO DPA)? Only laser, ink-jet,
impact are what most users want to know.
Status: Closed
Agreement: We agreed to delete the printer-type from IPP V1.0
altogether.
Pages 48-49: Printer-state, and printer-state-reasons. We
started to discuss Tom H's proposal and compare it with Bob H's new
formulations in the document. Keith C is writing up his ideas as well. We
will have a special telecon, Monday, 2/24, 2pm PST, 5pm EST, to discuss
the three proposals.