Subject: IPP> Minutes of IPP Weekly Conference call - Nove. 12, 1997

From: Roger K Debry <[email-masked]>
Date: Thu, 13 Nov 1997 08:54:49 -0500

Participating in the call were:  Ron Bergman, Harry Lewis, Xavier Riley,
Tom Hastings, Steve Zilles, Randy Turner, Bob Herriot, Ira McDonald,
and Roger deBry.   Steve Zilles moderated the call and Roger deBry
took minutes.

Everyone is urged to read through the latest versions of the IPP internet
dratfs and comment on issues for the last call. Issues will be collected
and be part of the agenda for the December PWG meeting in L.A.

Xavier Riley discussed his email outlining two approaches to handling
security for IPP. There was a lot of good discussion on this topic with
the following agreement:

1) We will have two URI's, distinguished by the scheme (http and https)
2) We will have two attributes in the model document, and in the directory
     to store these: Printer-URI and Secure-Printer-URI.
3) The implementation of http 1.1is mandatory.
4) The implementation of TLS/ SSL (associated with Secure-Printer-URI)
      is optional.
5) The implementation of Printer-URI and Secure-Printer-URI attributes
     is mandatory.
 6) An administrator must be able to configure the security options.
7) If Printer-URI has been "turned-off" by the administrator, a query
     will return "no-value".
8) If Secure printing is not implemented or has been turned off by the
     adminsitrator, a query of Secure-Printer-URI will return "no-value".
9) If a client somehow derives a URI and tries to connect and the
     service (e.g. Printer-URI) has been turned-off, an appropriate
      http error code will be returned.
10) If a printer supports both secure and non-secure printing,
       it will be recommended that administrators make the address
       portion of the URIs for secure and non-secure printing the same
       to make things easier for the end user.

Randy agreed to take the action item on suggested writeup of this
agreement for the model and protocol documents. He will work with
Scott and Bob on this.

Randy asked whether or not we should plan on an IPP bake-off
during the PWG meeting set for Portland in April. He wanted to make
the necessary room arrangements if there was interest in this. Most
felt that an electronic bake-off over the internet would work better, and
this was generally agreed to.

Bob Herriot raised the issue discussed in his email having to do with
handling operation attributes. He wanted to be sure that there was a
graceful way of handling (future) unsupported operation attributes,
thus avoiding a lot of major version changes. It was agreed that this
was a good idea.  Section 15.3 of the model documents needs to
be modified to provide a generic description covering all operations
and the agreement on operation attributes. Bob Herriot took the
action item to make the suggested changes. Tom Hastings agreed
to assist.

Carl-Uno asked Steve to get the Rationale document sent to the IETF.

Carl-Uno asked that the text for the application/ipp mime type be posted
to the discussion list for reading and approval by the group.

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 13 Nov 1997 09:41:24 -0500

The agreement Roger describes sounds good; one minor nit...

RKD> 9) If a client somehow derives a URI and tries to connect and the
RKD>    service (e.g. Printer-URI) has been turned-off, an appropriate
RKD>    http error code will be returned.

  Why impose that requirement?  That would mean that a printer without
  security (for whatever reason) would need to listen on the TLS port
  and implement enough of the handshake to negotiate no security so
  that it can send an HTTP error.  Similarly, a secure-only server
  would need to listen on the unsecured port just to send an HTTP
  error.  Just let TCP do the right thing - if they've constructed an
  invalid URI (one with the wrong scheme or port number in it), then
  it won't work, which is what should happen.  It really isn't the
  business of the IPP spec to say what will happen on a TCP port on
  which IPP is not available.

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

---

From: Jay Martin <[email-masked]>
Date: Thu, 13 Nov 1997 11:19:12 -0500

Roger K Debry wrote:

> [...snip...]

What exactly is the significance of this statement?  That is, what
kinds of thoughts were offered during the telecom regarding expected
methods for "configuring" the "security options"?

This is not a challenge, but rather a request for clarification.  It
would seem obvious (to some, anyway) that of course the administrator
must be able to configure a target element.  But why mention this fact
in a list in which the other items are far more detailed?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Thu, 13 Nov 1997 11:22:49 -0500

I entirely agree with Scott.  Supporting a service for which no
real support is provided doesn't jive with traditional approaches
(ie, just don't answer the call if you're not supposed to talk).

Was there some underlying goal/idea not stated in the minutes
for which this approach is necessary?

	...jay

---

From: Tom Hastings <[email-masked]>
Date: Thu, 13 Nov 1997 17:10:19 PST

Let me try to explain what we meant by:
6) An administrator must be able to configure the security options.

Support of http 1.1 is MANDATORY and implementation of TLS/SSL is OPTIONAL.

But some customers may want to have a secure-only printer.

Therefore, an implementor MUST NOT build a secure-only printer, but
MUST allow the administrator (the customer) to be able to configure
the Printer to be secure-only.

Its like requiring TV manufacturers who choose to make a color TV 
set to make sure that that color set also accepts black and white.
We are not allowing color-only sets.

Does this help?

Tom

---

From: "Xavier D. Riley" <[email-masked]>
Date: Fri, 14 Nov 1997 11:31:52 PST

I agree with Scott. I don't think we should mandate
what should happen in this situation.  It's not the existing
Web model.

--Xavier

>  which IPP is not available.

______________________________________________________________________
Xavier Riley                     
Xerox Corp.                      
Corp. Research & Tech.           Voice: 310-333-8329 / 8*823-8329   
701 S. Aviation Blvd ESAE-231    Fax: 310-333-6618 / 8*823-6618
El Segundo, California 90245     Email: [email-masked]
______________________________________________________________________