I've posted the Minutes in:
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-minutes-971029.doc .pdf .txt
If there are any problems with the minutes, we can discuss at the Wednesday
telecon, 11/5/97, 1:00 pm PST.
Here is the text version (without page headers and footers):
IPP Working Group Meeting Minutes
October 29-30, 1997
Boulder, Colorado
The meeting started on October 29 at 8:30 AM. The attendees were:
Ron Bergman - Dataproducts Corp.
Dennis Carney - IBM
Lee Farrell - Canon Information Systems
Steve Gebert - IBM
Jeff Haemer - QMS
Tom Hastings - Xerox Corp.
Bob Herriot - Sun Microsystems
Scott Isaacson - Novell
David Kellerman - Northlake Software
Carl Kugler - IBM
Harry Lewis - IBM
Carl-Uno Manros, Xerox, Corp.
Jay Martin - Underscore
Pat Nogay - IBM
Jerry Podojil - Genicom
Stuart Rowley, Kyocera
Yuji Sasaki, JCI
Ron Sherer - Peerless
Randy Turner - Sharp
Atsushi Uchino - Epson
Dale Wick, True Spectra
Atsushi Yuki - Kyocera
Lloyd Young - Lexmark
Peter Zehler, Xerox, Corp.
1. Agenda
1) What is needed to make the Model and Protocol documents eady to initiate
the WG last call from and that priority ONE is to make sure we get any
remaining comments reviewed, so that we can get the "final" draft version
of the documents out and start the last call some time next week.
Other subjects, which we decided to leave out from Version 1.0 or other
left overs are:
2) The Mapping document to LPD/LPR
3) Asynchronous Notifications
4) Document level attributes
5) Dictionary Syntax
6) IPP use of TLS (when that spec gets frozen)
7) IPP prototyping/interoperability testing
2. Model and Semantics Document Issues
The following issues were identified and the indicated resolutions were
agreed to. Scott will include them in the next version of the Model and
Semantics document for review by the DL.
2.1 Adding new Operation attributes in the future?
It was agreed that adding new Operation attributes would require that the
major version number be incremented. So a Printer object SHALL reject
requests that contain Operation attributes that are not supported,
independent of the setting of the "ipp-fidelity" attribute. Thses
requirements will help with interoperability.
NOTE: Job Template attributes that a Printer object does not support SHALL
be ignored when the "ipp-fidelity" attribute is 'false', so most of the
registered and private extensions will be in the Job Template attributes
group, not the Operation Attribute group.
1.2 Remove "document-charset" Operation attribute?
We don't need this attribute for PostScript=99. PCL drivers embed an escape
sequence to indicate the charset of the document, so we don't need this
attribute for PCL. We agreed that any media type that needed a charset
specification should indicate it in the media registration specification.
Even 'application/octet-stream' for PDL sniffing does not need a charset;
the Printer object will assume the printer's default charset, if the
document doesn't have an embedded indication of charset.
1.3 Get-Attributes requesting an unsupported attribute - error or ignore?
We decided that the Printer object SHALL ignore any requests for
unsupported attributes and return no indication of such an occurrence. The
client looks at the attributes that are returned which are only the
supported attributes.
1.4 How to return supported attributes whose values are not yet known?
We decided that to use an out-of-band coding for all attribute syntaxes,
including enums and integers. So, unlike the Printer and Job Monitoring
MIBs, the -2 value will NOT be used for integers and the +2 will not be
used for enums to indicate a value that is not yet known to the Printer
object. Mapping from the MIB representation to the IPP representation of
unknown is straightforward for implemenations that support both IPP and the
Printer or Job Monitoring MIBs.
1.5 The term "imposed page" vs. "impression"
We agreed that we didn't need the new term "imposed page" because
"impression" is the same.
1.6 Should the Model require conformance to the Protocol?
We agreed to remove the statement in the Model document that an
implementation MUST also conform to the Protocol document. Retaining the
statement would preclude ever having a different protocol document. The
protocol document already requires conformance to it.
1.7 When "ipp-attribute-fidelity" =3D 'false' MAY an IPP object reject a
request?
We agreed that when "ipp-attribute-fidelity" is 'false', that the IPP
object MUST try its best to perform the create operation and SHALL not
reject the create job operation.
1.8 Should IPP attributes include ISO 10646 level 3?
Since the IPP protocol does not require any attribute matching, the
difficulty that level 3 introduces of multiple ways to encode the same
(accented) letters is not a problem. So we agreed to remove the
restriction that utf-8 'text' and 'name' attributes had to be ISO 10646
level 2 or less.
[Editor's note: but the Cancel-Job operation does require the IPP object to
make sure that user requesting the operation is the same as the one that
submitted the job, so that there is a comparison of user names that could
include accented letters that use level 3 encoding with non-spacing
accents. Also if the security policy is that users can only get attributes
for their own jobs, then the IPP object will also be doing compares for
Get-Attributes and Get-Jobs operations on user names submitted with the
request to those stored with the job.]
1.9 Natural-language override: differs between Model and Protocol
We agreed to use the mechanism in the Protocol document with the
CompoundValue tag that indicates the number of following attribute values
that are taken together, rather than just have two values,
'naturalLanguage' followed by 'text' or 'name'. The CompoundValue is more
general and less ad hoc. It could be used for other purposes in the
future. In the case of the natural-language override, the value of the
CompoundValues value SHALL be as '2', immediately followed by the
natural-language value followed by the 'text' or 'name' value. A
CompoundValue is then treated as if it were a single value. =20
The Model document will say nothing about the representation of the
natural-language override or the concept of CompoundValue. The protocol
document will introduce the concept of CompoundValue.
1.10 Are Operation attributes MANDATORY?
We re-affirmed that all operation attributes are MANDATORY for the Printer
object to accept and support in requests and for the client to accept in
responses.
1.11 Do we need both "printer-uri' and "print-tls-uri"?
We agreed that there should be only one uri for a Printer object. So
delete the "printer-tls-uri attribute from both the Printer object and the
directory schema. If the one URI has a scheme that requires security, then
that is sufficient. The "printer-uri" attribute will remain single-valued
in both the Printer object and the directory entry.
1.12 What security is MANDATORY in IPP/1.0?
We agreed that clients MUST issue and Printer objects MUST accept TLS with
at least SSL3 framing. The client and the Printer object MAY then
negotiate down to null (no-auth). But a client SHALL NOT start out without
TLS and a Printer SHALL NOT accept non-TLS. It is expected that when TLS
is finished, that it will have SSL3 compatibility, since so much SSL3 is
deployed today.
1.13 Do we need "security-schemes-supported"?
We agreed to delete security schemes supported, since now the Protocol
document will MANDATE that the HTTPS: scheme be used for IPP.
ACTION ITEM (Randy, Carl-Uno): work on an Appendix or implementation notes
that could be a separate information RFC on how the security negotiation
works.
1.14 Should the Protocol recommend a port to use when not using the default
port for the scheme in use?
The default port for HTTP: is 80. The default port for HTTPS: is some
other value which becomes the default port for IPP. The Protocol document
will mention this default port. If an alternate is wanted for IPP, the
Protocol document will recommend a particular (different) port that will
have to be explicit in the URI.
There is a problem in UNIX in that an explicit port number (below) 1024 can
be used only if the client is logged in as root. No fix for this problem
was forth coming.
ACTION ITEM (Carl-Uno): Apply for this alternate port for IPP.
1.15 Remove reference to Send-URI in Validate-Job
Section 3.2.3: Remove the reference to Send-URI in Validate-Job.
1.16 MUST return all unsupported attributes, not just the first one
Section 3.2.1.2: We agreed that the Printer object MUST return all
unsupported attributes and attribute values in the create operation
response, not just the first unsupported attribute or value.
Implementations have found that it isn't more difficult to return all and
returning all will mean that the client can fix up all problems and try=
again.
1.17 Remove vendor extension for per-document attributes
Section 3.2.1.1: Remove the mention of vendor extension for per-document
attributes. We need to work together on this extension in order to keep
interoperability.
1.18 Auto-sensing is best-efforts
Section 4.1.9: Add a note that application/octet-stream auto-sensing is not
absolutely guaranteed, but customers love it none-the-less.
3. Comments on the Protocol document
The following agreements were reached on the Protocol document. Bob will
include them in the next version of the Protocol document for review by the
DL.
3.1 Remove the redundant attribute syntax descriptions
The Protocol document will only explain the representation of each
attribute syntax, not the semantics. The model will describe only the
semantics.
4. Other Documents
The following additional documents will be produced and the indicated
actions taken:
4.1 LPD Mapping to IPP document
Bob Herriot says that the LPD Mapping document is finished. The last July
Internet-Draft is the final version. It will become an informational RFC.
ACTION ITEM (Carl-Uno): Announce it for a two week WG last call=
immediately.
4.2 The Rationale document
The Rationale document is being updated by Steve Zilles. It will become an
informational RFC. It is desirable for it to be available when the Model
and Protocol documents are.
ACTION ITEM (Steve Zilles): Send the final Internet-Draft to the IETF
Secretariat and announce a two week WG last call when the Secretariat
announces the I-D.
4.3 The Requirements document
Don Wright has finished the requirements document. It will be an
informational RFC.
ACTION ITEM (Carl-Uno): Announce it for a two week WG last call.
5. Asynchronous Event Notification
After much discussion back and forth we agreed that the WG needs to work on
a program parsable representation for asynchronous events after forwarding
IPP/1.0 Model and Protocol documents to the IESG. The IPP WG charter
includes such. We removed the asynchronous event notification from IPP/1.0
document because we only had a simple text representation that programs
might try to parse. The experience with PostScript error messages being
only text made us realize that leaving in only text messages would cause
the same problems all over again. One approach would be to define a
multi-part/alternative media type that contains a program parsable
alternative and an text/plain alternative. The recipient chooses which
alternative to use. Such a media type could be sent using a mailto: scheme.
The second problem with asynchronous event notification is the transport of
the event messages. The Simple Event Notification System Environment
(SENSE) is a candidate. Jay Martin presented its concepts to the group.
It has been implemented and deployed in printing applications over the last
two years. It seems general enough for IPP needs. It is also very
portable. The specifications are on the PWG FTP server under:
ftp://ftp.pwg.org/pub/pwg/SENSE/
In order to be used with IPP, a specification of the SENSE properties to be
used in a publication and an edition needs to be written and agreed to for
use with IPP. Otherwise, interoperability between one vendors subscribers
and another vendors publishers is not possible. See separate minutes
produced by Jay to the SENSE DL.
The IPP WG can produce another RFC which augments the current IPP Model and
Protocol documents, just as MIME has done. We need to specify this as soon
as possible, least implementers invent their own representations and
transports and the opportunity for interoperability is lost.
This topic will be on both the next IPP WG agenda and the IETF IPP agenda.=
=20
6. Interoperability Testing
Randy Turner and Peter Zehler indicated that they were close to trying
pair-wise interoperability testing over the Internet. Peter is installing
a prototype outside the Xerox firewall. Randy indicated that he has the
same capability. Others are encouraged to participate.
agreed that we need to develop a specification of a set of operation
requests, including the attribute values supplied and the expected
attribute and status code responses. Error conditions need to be included.
This specification was called a set of scenarios and needs to be=
executable.
7. Next IPP WG meeting, 12/3/97, Los Angeles
The next IPP WG meeting will be Wednesday, in Los Angeles. Reservations
need to be make by 11/7/97 to get the low rate. Else the rate doubles. We
will probably only need one day, which will be Wednesday.
8. Next IETF meeting, week of 12/8/97, Washington DC
Carl-Uno has requested a two hour slot. We may only need one hour. We
agreed that it was important to have the slot. We can reduce the time near
the end of November.
The meeting adjourned at 5:30 PM.