ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-01297.txt
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-01297.pdf
**********************************************
* Don Wright don@lexmark.com *
* Product Manager, Strategic Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
-----------------------------------------------------------------
Internet Printing Project Meeting Minutes
December 3, 1997
Los Angeles, CA
The meeting started on December 3, 1997 at 8:30 AM led by Carl-Uno Manros.
These minutes were recorded by Don Wright. The attendees were:
- Randy Turner - Sharp
- Ron Bergman - DataProducts
- Peter Zehler - Xerox
- Lee Farrell - Canon
- Philip Thambidurai - Okidata
- Bob Pentecost - HP
- Don Wright - Lexmark
- Keith Carter - IBM
- Steve Zilles - Adobe
- Roger deBry - IBM
- Tom Hastings - Xerox
- Scott Isaacson - Novell
- Carl-Uno Manros - Xerox
- Dave Kellerman - NorthLake
- Stuart Rowley - Kyocera
- Bill Wagner - DPI/Osicom
- Bob Herriot - Sun
- Chuck Adams - Tektronix
- Henrik Holst - I-Data
- Frank Zhao - Panasonic
- Yuji Susalai - Japan Computer Industry
- Atsushi Uchino - Seiko-Epson
- Rick Yardumian - Xerox
- Xavier Riley - Xerox
- Gary Roberts - Ricoh
- Dale Wick - TrueSpectra
- Mike Moldovan - Genoa Technology
- Gary James - Genoa Technology
- Jun Fujisawa - Canon
- Harry Lewis - IBM
- Kevin Osborn - Sun (JavaSoft)
Carl-Uno Manros reviewed the agenda for the day and dealt with the
administrivia of the meeting.
ISSUES
------
Scott Isaacson started off the meeting by going through the issues list
which
is posted on the server as
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-issues.pdf
M01) Versioning rules for major/minor revisions - resolved per the
suggested
changes in "ipp-section-15-3-norev.doc" (posted on the server.) Private
extensions do not cause the major/minor versions to change. Only changes
to
the documents (protocol and model) cause a change to the versions.
Implementations shall accept all request with the same major version and
any
minor version. Fidelity will control the behavior should unknown attribute
or
operations be encountered from a different minor version.
-- Add statements in the versioning section
* Not reassign objects between versions
* Each major version will state what prior versions are to be
supported
M02) Issues concerning groups in operations:
- What should a printer do if an operation contains an unexpected
group?
** see proposed new 15.3.3.1
- What should a printer do if the correct groups are present but in
the
wrong order?
** see proposed new 15.3.3.1
- If Get-Attributes is returning no job/printer attributes, what does
it return?
** Clients should send the group tag even if there are no
attributes.
The general philosophy should be to be conservative in what is sent and
liberal in what is accepted. Overall for groups and attributes, group tags
may be included with no attributes or the group tags can be omitted.
Therefore receivers of data shall accept both.
M03) Return not supported operation attributes in Get-Attributes operation.
** Not an issue because all the operation attributes are mandatory but
allow for the group to show no support for extensions
M04) Moving job-k-octets, job-impressions, compression and job-media-sheets
to
become optional operations attributes?
** These operation attributes get mapped into job description
attributes.
Now all job-template attributes are affected by fidelity.
Section
3.1.1 of the model document needs to be updated to reflect these
changes.
M05) Keep document-format as operation attribute
** Yes
M06) See issues M04
M07) Upper bounds
** See "ipp-min-max" on the server. Generally, attributes will be
sized by type but on an attribute by attribute basis, special
cases will be dealt with.
M08) Granularity of error messages? This has been addressed in the latest
version.
M09) Semantics of unsupported and supported. This has been addressed in
the
latest version.
M10) Statement that validation is attribute specific. This has been
generally
fixed in the latest version.
M11) Add semantics to section 3.1.5.2 about requesting-user-name operation
attribute.
** Bob Herriot will write up some clarifying language for this
section. Remove the requirement for creating a unique name if
one is not provided. The name does not have to be unique.
M12) Add (1:MAX) to limit in section 3.2.6.1 of the model.
** OK
M13) We will remove "copies-collated-*"
M14) Change SHOULD to SHALL in section 4.1.9
** Both SHOULDs need to be changed to SHALLs in this section.
M15) Why is "attributes-natural-languages" special?
** When a client submits something and specifies the language it is
used
as a "post-it". We will change the following:
natural-language -> generated-natural-language-default
natural-language-supported ->
generated-natural-language-supported
We will add the -default to "charset" and "document-format"
M16) Semantics of multiple-document-handling (section 4.2.4)
** Not resolved for Version 1.
M17) Semantics of Page-ranges attribute (section 4.2.7) Change to specify
non-
overlapping ranges provided in ascending order.
M18) Fixed in "ipp-section-15-3-norev.doc"
M19) No
M20) Conformance Language for natural-language
** Optional for object to support
M21) Conformance Language for media-ready
** Optional
M22) What status code is returned when printer is "accepting jobs" is
false?
** Add an error code "server error - not accepting jobs" will be
added/
M23) Semantics of server-error-version-not-supported need clarification
** See changes suggested in "ipp-model-last-call-comments-th.doc"
M24) Semantic changes needed in 15.3
** See "ipp-section-15-3-norev.doc" The series of checks provided in
this new section are semantic examples and not conformance
requirements. Some implementations may be softer and allow
some non-conforming operations/attribute. Some of the semantics
and interactions contained in the section are important but are
not found elsewhere.
M25) Occurrences of HTTP in Model document
** The references to HTTP will be removed from the MODEL document.
M26) Internationalization clarifications
** Section 7: add classification of various text attributes and their
source and interaction of language and charset with them.
** Revisited M15 and change to natural-language-configured. Scott
will take a work item to clarify this.
M27) Align our syntax descriptions with
<draft-iesg-iana-considerations-01.txt>
** Carl-Uno Manros and Steve Zilles will explore this with our area
directors.
P01) Do we want to define and mandate a client-specified transaction ID.
** Yes, it will follow the version number in the protocol, it will be
mandatory and will be 4 bytes and the range 0 -> (2^31)-1
P02) Does text on the Network Byte Order (protocol, sect 3) need
improvement?
** Bob Herriot will fix.
P03) We need a better description of how HTTP chunking is done by IPP.
** Bob Herriot will add some text about this and reference the
HTTP/1.1
document as a reference for people implementing both IPP and
HTTP.
** Some additional areas needing clarification were identified and
will
be written up by several people and added to the protocol
document as "hints" or "implications of IPP over HTTP"
P04) Do we need to refine CompoundValue?
** We have removed CV and replaced it with two new tags called
"localized-text" and "localized-name" This will be written up in
the next version of the document.
I02) Revise definition of Application/IPP so it can be run over other
transports.
**This will be fixed in the documents.
P05) OK
P06) A long discussion ensued over the idea of using a special marker to
indicate the end of the header and also indicating that there is or
isn't
more data.
** Resolution: Rename the "data" tag to be called the
"end-of-header",
"end-of-attributes" or "end-of-parsing" tag that indicates the end
of the IPP header.
GENOA
-----
A presentation was made by Gary James from Genoa Technology about what
Genoa
is doing testing protocols. A discussion followed about how Genoa would do
an
IPP test suite. Genoa has looked at the IPP protocol and they are in the
process of making a business decision to prioritize the various other
projects
they are investigating. They currently plan to do an IPP test suite and
are
trying to decide when to do it. They expect a decision by early '98.
ADOBE
-----
Steve Zilles made a presentation on some work on Job Tickets that is being
done by Adobe. Version 1.0 of the Job Ticket specification was completed
on
October 6th. The document is available on the Adobe Web site in the
developer's area in the tech notes area as tech note #5620.
ISSUES
------
P07) Wording has been changed.
P08) Remove the issue statement from the section.
P09) Bob Herriot will add some additional examples in this section.
P10) When does the IPP server rejects an operation?
** Randy has an action item to write up. The suggested tests listed
in
the new 15.3 section says not to quite checking early, i.e. when
the first error is found.
P11) OK, Bob will incorporate new wording into the protocol document based
upon wording from Carl-Uno.
P12) Port numbers for IPP?
** Carl-Uno will request an IPP and an IPP/TLS port.
S01) Accept Randy Turner's text
S02) Accept Randy Turner's text
S03) Make "digest authentication" optional
** Yes, IPP will defer to the HTTP/1.1 security requirements.
S04) Security terminology
** Leave the wording as is.
S05) Move security to earlier in the document.
** According to the IETF, Section 8 is suppose to be the security
section. We will add a forward reference earlier in the
document pointing to sect. 8.
D01) Alignment of IPP with Service Location Protocol Printer Scheme.
** Scott Isaacson will coordinate with the SRVLOC people.
I01) Parameters for application/octet-stream MIME type.
** Application/octet-stream does not support CHARSET, OK -- no action.
I03) Register document formats as MIME media types
** Action item for Tom Hastings to post a list of what will be
registered
and what will not to the mailing list. He will provided a
deadline for comments back to him.
I04) Register application/ipp with IANA
** Action item for Carl-Uno to do this after Ira MacDonald posts the
text
to the mailing list.
Scott Isaacson reviewed the changes made at the Boulder meeting that were
reflected into the "last call" document. The following caused additional
discussion and/or decisions:
1) We will remove the "0" value of number-up and be silent on the
embellishment
issue relating to number up.
2) A discussion was held about issue of time. We decided to leave the time
attributes as currently defined.
DOCUMENTS
---------
After the IETF meeting in Washington DC, we will send the resultant
documents
to the mailing list first and everyone should do a quick review before
sending
we send them to the IESG as the last call document. We expect to do this
before the end of the year. The Rationale and Mapping documents may need
some
updates based upon today's work before going out to the IESG for last call.
The Requirements document will go as is to the IESG for last call.
The meeting was adjourned at 5:30 PM PST.