Minutes IETF IPP WG Meeting, 97/12/10, Washington DC
1-3PM, Executive Meeting Room

These minutes were taken by Steve Zilles.

Carl-Uno Manros began the meeting with an overview of the documents and 
the agenda for the meeting:

Review suggested resolution of existing issues on:
- Model and Semantics document, presented by Scott Isaacson
- Protocol Specification document, presented by Bob Herriot

In the recording below, issues and their suggested resolution are recorded 
as presented (sometimes with some expansion for clarity). In most cases 
there was no discussion and the proposed solution was accepted as presented. 
If there was a discussion, this is recorded after the presented solution and 
if a different decision was made, this is recorded after the discussion as 
a decision.

Model Document Issues, Scott Isaacson 

1.  Major/Minor Versioning Rules
Mandate common encoding across all versions
All elements added in a new minor version can be ignored
New major version indicates new support requirements

2.  Allow empty attribute groups
Be conservative in what is sent; send an empty group
Be liberal in what is received; allow missing group on reception

3.  ALL operations MAY return "Unsupported Attributes"

4.  Define protocol value-size upper bounds for 
URIs, charsets, natural languages, identifiers, ... 

5.  MUST-implement requirements for text and name strings; each string has a 
maximum length specification:
some 63 octets, others 127 or 1023 octets

Clarified validation checks for operation processing

Non-secure implementation
client supplies "requesting-user-name"
If client does not supply a name, the printer will generate one (which need 
not be unique)

Discussion:
Is an authenticated mode required of all Printers

Keith Moore would like to have this be true; without it the protocol will not 
be interoperable; that is, two implementations of the spec may not be able to 
find a common (authenticated) communication path

Keith asserts that the current rules require this, because use of an Internet 
accessible printer will require authentication; Keith believes that submitting 
it as documented will cause kick back from the IESG. 

But, for interoperability, it is not the case that both client and server must 
do all the mechanisms as long on one or the other must do all; that means that 
requiring all clients to do the secure solution is enough to meet Keith's 
understanding of the rules

Jim Gettys: HTTP has an issue raised by Lotus to multiple servers, serving a 
single site; It appears that Digest Authentication (with a few tweaks based 
on an idea of Paul Leach) may meet this need.(and that Microsoft and Netscape 
may be likely to implement Digest) Details on this discussion will play-out on 
the HTTP mailing list over the next few weeks.

Keith Moore: Whether Digest Authentication is enough is not an issue of whether 
it is secure enough, but whether this solution is sufficiently scalable (Jim G 
asserts that Paul Leach's solution may solve the scalability issue)

Keith points out that Diffie-Hillman is a (now) unencumbered mechanism for key 
exchange and should be relatively easy to implement.

It is noted that there are two different classes of interoperation over the 
Internet: (1) remote access to a private resource (such as the printer on my 
desk) 
versus (2) providing a service to all comers (such as a Kinko's service) over 
the Internet. Scalability is not an issue in the first case. 

It was suggested that we identify the basic mode as "authenticated" mode 
(because Digest Authentication is already mandated for all HTTP/1.1 clients) 
and the full TLS based mode as secure mode.

Decision:
Digest authentication is already mandated for all HTTP/1.1 clients
IPP will mandate TLS for all clients

8.  Removed "copies-collated" attribute

9.  Identified sources for all text and name valued attributes:
end user
device vendor,
operator
administrator
allow any natural language for non-generated strings
name change to "generated-natural-languages-supported"

10. Keep "charset-supported"

11. Clarified semantics of "page-range" attribute

12. Support for Media attributes
If supporting "media-default", then MANDATORY
If supporting "media-supported", then MANDATORY
If supporting "media-ready", then OPTIONAL

13. Added missing status codes
"server-error-not-accepting-jobs"
"server-error-version-not-supported"

14. Asserted that IPP is already aligned with <draft-iesg-iana-considerations-01.txt>

15. Made "application/ipp" a "common usage" media type
added "request ID" to allow matching of responses to corresponding request for 
protocols other than HTTP (e.g. SMTP) included all parameters, including the 
target object URI, within the application/ipp body

16. Security
Allow for "non-secure", really "authenticated" servers
If Privacy and/or Mutual Authentication is implemented, then it Shall be TLS
For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows

Decision:
rename "non-secure" to "authenticated"
rename "secure" to "private and authenticated" (or something similar

Discussion:
WEBDAV has been asked to not allow basic authentication.

17. Provide input to the SVRLOC Printer Scheme I-D

18. Register all the SNMP printer languages as a (MIME) media types with cross 
references to the SNMP enums

19. Register "application/ipp" as a media type
Keith said the preferred method for handling the MIME type registration is to 
put the registration text (as per RFC2048) into the standards track RFC that 
uses/defines it. IANA should then automatically add it to the registry within 
a few days of the publication of the RFC.

New Issues:

20. Should we register new ports for IPP use
Keith Moore: a reason for a separate port number is to allow firewalls to be 
configured to allow or block the printing port.

But, Keith observes that firewall usage is typically to block all access except 
to particular servers and if HTTP is not allowed, then it is likely that printing 
would also not be allowed so this is not a big issue. Hence, Keith is neutral on 
registering a port for IPP.

IESG has made TLS remove creation of new ports for other protocols than HTTP. 
Ones that are already deployed were kept, but no new ones. Therefore, we should 
not have a separate new port for IPP over TLS.

Other than the port discussion, no new issues were raise


Protocol Document Issues since August 1997, Bob Herriot

1.  Attribute Group Tags
Sender (of request or response) SHOULD send attribute group tag with no following 
attributes with the exception of the unsupported-attributes-tag which SHOULD be 
omitted.
Recipient (of request or response) MUST accept as equivalent representations of 
an empty attribute group:
- attribute group tag with no following attributes
- expected but missing attribute tag

2.  Identified a subset of the tag types (0-0xf) as being attribute group tags 
(some of which have not yet be assigned); these should be handled like attribute 
tags by any application/ipp recipient. The subset of tag types (0x10-oxff) are "value 
tags".

3.  A recipient of a request or response MAY skip all attributes in an unknown 
group.

4.  Printer-uri and job-uri 
MUST be on HTTP request line
MUST also be in operation attributes

5.  Job operations MUST be supported with both
job-uri target
printer-uri target with job-id attribute

6.  Create-job operation returns job-uri and job-id

7.  Handling of localized text and names
Added two new data types:
localized text
localized name
both of these are represented as an octet string with four fields:
length of natural language identification
natural language identification (per RFC
length of text/name
content of text/name

8.  Request ID added to all requests and responses
server returns received request-id in the response to the request that had the 
request-id client may match response with requests using the request-id; client 
is responsible for management of request id numbering space; in HTTP, the client 
can always use 0 as the request-id because HTTP guarantees responses in the order 
requests are made.

9.  Renamed 'data-tag' to 'end-of-attributes' tag

10. Added new out-of-band values for
no-value
unknown

11. Definition of status codes and operations moved to model document

No new issues were raised at the meeting

Mapping between LPD to IPP, Bob Herriot, the document was updated as follows:

1.  added statement that this is informational and its intent is to help implements 
of gateways between IPP and LPD

2.  job-id 
now both job-id and job-uri are available
allows job-id to be same as LPD job-id in relevant cases

3.  job-originating-host was removed from IPP model; IPP-to-LPD must use some other 
means to supply the 'H'(host) parameter.

4.  job-k-octets was clarified to count octets in one copy, not all copies; file 
size in lpq response does contain copies

5.  Notification was removed from the IPP model; therefore support for LPD email 
notification is not possible

6.  For document format, SNMP Printer MIB enums were replace by (MIME) media types

7.  Authentication
job-originating-user replaced by job-originating-user-name
value is (explicitly) a human readable name
value comes from underlying authentication mechanism and the attribute: 
requesting-user-name

No other issues were raised

Since all issues presented had a proposed solution that was acceptable to the 
meeting; final copies of the documents, containing the proposed resolutions, 
will be prepared and circulated to the mailing list by the end of the week. 

Assuming there are no significant comments received by Dec 18, the revised 
documents will be transmitted to the IESG for processing before the end of the year.

IPP Summary Paragraph

The standards track documents on the IPP Model and Semantics and the IPP Protocol 
Specification and the informational documents on IPP Requirements, IPP Rationale 
and Mapping between IPP and LPD were discussed. WG final calls for these had 
either expired or were about to expire. Proposed solutions to all known problems 
were reviewed (and, where necessary, corrected) during the WG meeting. Unless 
some new issue arises, it is the intent that final documents that include the 
proposed solutions will be given to the IESG for final processing before the end 
of the year. With this action, we consider the WG's charter to be fulfilled and 
do not expect to meet at the next IETF meeting.